The following change to dlls/mscms/profile.c revision 1.6 date: 2004/11/21 15:48:18; author: julliard; state: Exp; lines: +135 -3 Implement and test GetColorProfileElementTag, GetCountColorProfileElements and IsColorProfileTagPresent. Stub GetStandardColorSpaceProfile{A,W}. breaks FreeBSD 4.10 (with XFree86-4.3.0) as follows: gmake[2]: Entering directory `/.amd_mnt/nashira/files5/test/wine/dlls/mscms' /sw/gcc-3.3.4/bin/gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o profile.o profile.c profile.c: In function `GetColorProfileElementTag': profile.c:142: error: `LCMSICCPROFILE' undeclared (first use in this function) profile.c:142: error: (Each undeclared identifier is reported only once profile.c:142: error: for each function it appears in.) profile.c:142: error: `cmsprofile' undeclared (first use in this function) profile.c:142: error: parse error before ')' token profile.c: In function `GetCountColorProfileElements': profile.c:174: error: `LCMSICCPROFILE' undeclared (first use in this function) profile.c:174: error: `cmsprofile' undeclared (first use in this function) profile.c:174: error: parse error before ')' token gmake[2]: *** [profile.o] Error 1 gmake[2]: Leaving directory `/.amd_mnt/nashira/files5/test/wine/dlls/mscms' Gerald -- Gerald Pfeifer (Jerry) gerald(a)pfeifer.com http://www.pfeifer.com/gerald/
On Monday 22 November 2004 09:48, Gerald Pfeifer wrote:
gmake[2]: Entering directory `/.amd_mnt/nashira/files5/test/wine/dlls/mscms' /sw/gcc-3.3.4/bin/gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o profile.o profile.c profile.c: In function `GetColorProfileElementTag': profile.c:142: error: `LCMSICCPROFILE' undeclared (first use in this function)
That code is protected by #ifdef HAVE_LCMS_H, so I would be interested to know if (and where) you have lcms.h installed, whether configure has properly detected it, and if so, what your lcms.h looks like. Can you send me those details? -Hans
On Mon, 22 Nov 2004, Hans Leidekker wrote:
profile.c:142: error: `LCMSICCPROFILE' undeclared (first use in this function) That code is protected by #ifdef HAVE_LCMS_H, so I would be interested to know if (and where) you have lcms.h installed
/usr/local/include/lcms.h, coming from a package called lcms-1.09.
whether configure has properly detected it
/* Define to 1 if you have the <lcms.h> header file. */ #define HAVE_LCMS_H 1
and if so, what your lcms.h looks like. Can you send me those details?
Sure, thanks for looking into that! I'm Cc:ing lcms.h and config.h on this message. Gerald
On Monday 22 November 2004 12:15, you wrote:
/usr/local/include/lcms.h, coming from a package called lcms-1.09.
Right, that's a very old version from 2001. Since then the number of APIs has nearly doubled: $ grep LCMSAPI tmp/lcms.h | wc -l 88 $ grep LCMSAPI /usr/include/lcms.h | wc -l 162 I'm sure we will be needing many of those newer APIs. Is there any chance for you to upgrade your lcms.h to 1.13? -Hans
On Mon, 22 Nov 2004, Hans Leidekker wrote: [...]
Right, that's a very old version from 2001. Since then the number of APIs has nearly doubled: [...] I'm sure we will be needing many of those newer APIs. Is there any chance for you to upgrade your lcms.h to 1.13?
A better solution would probably be to check for one of the newer APIs in configure.ac (or the LCMSICCPROFILE structure if that is possible). -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Avoid the Gates of Hell - use Linux.
On Tuesday 23 November 2004 10:21, Francois Gouget wrote:
I'm sure we will be needing many of those newer APIs. Is there any chance for you to upgrade your lcms.h to 1.13?
A better solution would probably be to check for one of the newer APIs in configure.ac (or the LCMSICCPROFILE structure if that is possible).
That's another solution but I'm not sure if it's a *better* solution. It will mean that Gerald won't see any compiler errors, but it will also mean he builds an MSCMS dll without or with limited lcms support. At this stage of development I don't think it's reasonable to try to support an old version of lcms that has only half of the APIs compared to the latest. But it's orthogonal I guess, we should encourage packagers to compile with support for recent lcms as well as prevent breakage on old headers. Newer lcms.h has a version #define which we could use for a configure check b.t.w. -Hans
On Tue, 23 Nov 2004, Hans Leidekker wrote:
On Tuesday 23 November 2004 10:21, Francois Gouget wrote:
I'm sure we will be needing many of those newer APIs. Is there any chance for you to upgrade your lcms.h to 1.13?
A better solution would probably be to check for one of the newer APIs in configure.ac (or the LCMSICCPROFILE structure if that is possible).
That's another solution but I'm not sure if it's a *better* solution. It will mean that Gerald won't see any compiler errors, but it will also mean he builds an MSCMS dll without or with limited lcms support. At this stage of development I don't think it's reasonable to try to support an old version of lcms that has only half of the APIs compared to the latest.
What I meant is that we should check for one of these new APIs that we need, and if we don't find it we should just do as if lcms.h was missing. I.e. if your lcms library is too old, then Wine won't use it at all. That should keep things pretty much as simple as now, while avoiding compilation errors for people with old libraries. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Linux: Because rebooting is for adding new hardware
On Tuesday 23 November 2004 14:07, Francois Gouget wrote:
What I meant is that we should check for one of these new APIs that we need, and if we don't find it we should just do as if lcms.h was missing.
Yes of course, I meant that too, and we should do that. But you presented this as a better solution for the breakage Gerald experienced than asking him to upgrade to lcms 1.13, which I don't agree with. Building as if lcms.h is missing would result in a mostly non-functional MSCMS dll and especially with him being the maintainer of the FreeBSD Wine port (IIRC) that could affect a large number of people. -Hans
On Tue, 23 Nov 2004, Hans Leidekker wrote:
What I meant is that we should check for one of these new APIs that we need, and if we don't find it we should just do as if lcms.h was missing. Yes of course, I meant that too, and we should do that. But you presented this as a better solution for the breakage Gerald experienced than asking him to upgrade to lcms 1.13, which I don't agree with.
Hans, the issue is not me upgrading to lcms 1.13 (which I'd do in a moment). Rather the problem is that we cannot (easily) require all users of Wine or ports (e.g. the FreeBSD ports collection) to upgrade. In many cases this will boil down to a broken/not broken distinction rather than supports cms/doesn't support cms. Unfortunately.
Building as if lcms.h is missing would result in a mostly non-functional MSCMS dll and especially with him being the maintainer of the FreeBSD Wine port (IIRC) that could affect a large number of people.
You remember correctly. ;-) I guess my preferred solution would be for me, personally, to update to lcms, but at the same time see a patch as discussed between Francois and you go into WineHQ CVS. I can take care of the former, but I'd appreciate your help on the latter. ;-) Thanks, Gerald -- Gerald Pfeifer (Jerry) gerald(a)pfeifer.com http://www.pfeifer.com/gerald/
On Tue, 23 Nov 2004, Hans Leidekker wrote:
On Tuesday 23 November 2004 14:07, Francois Gouget wrote:
What I meant is that we should check for one of these new APIs that we need, and if we don't find it we should just do as if lcms.h was missing.
Yes of course, I meant that too, and we should do that. But you presented this as a better solution for the breakage Gerald experienced than asking him to upgrade to lcms 1.13, which I don't agree with.
I do think it's a better solution. Just like it's better to let Wine compile even if the ALSA development libraries are not installed or obsolete, eventhough the resulting winealsa is going to be non-functional. If you want to make sure that users don't accidentally build Wine without lcms support you could modify configure.ac to print out a warning like we do for ALSA & co: if test -z "$ALSALIBS" then echo "*** Alsa not detected. The winealsa.drv.so driver will be a dummy." fi However i'm not sure that's warranted. A related question is which version is normally shipped on FreeBSD (and I guess that's likely different for 4.x and 5.x). I guess that for 4.10 this is 1.09 but for 5.x it's probably a more recent version. Next question is: with the threading / memory allocation issues, does Wine have a chance to run right on 4.x? If not and lcms is up-to-date enough in 5.x then supporting the old 1.09 is probably not a priority. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Demander si un ordinateur peut penser revient \xE0 demander si un sous-marin peut nager.
On Wednesday 24 November 2004 13:13, Francois Gouget wrote:
I do think it's a better solution. Just like it's better to let Wine compile even if the ALSA development libraries are not installed or obsolete, eventhough the resulting winealsa is going to be non-functional.
Agreed again about making it at least compile. But that's not the issue I was talking about. My concern is packagers like Gerald that may be building suboptimal packages because they don't use the latest development headers.
If you want to make sure that users don't accidentally build Wine without lcms support you could modify configure.ac to print out a warning like we do for ALSA & co:
if test -z "$ALSALIBS" then echo "*** Alsa not detected. The winealsa.drv.so driver will be a dummy." fi
Ah, now you're talking. But for some reason I couldn't find those lines in my version of Wine.
A related question is which version is normally shipped on FreeBSD (and I guess that's likely different for 4.x and 5.x). I guess that for 4.10 this is 1.09 but for 5.x it's probably a more recent version. Next
I don't think lcms is shipped with FreeBSD is it? It's in the ports collection. I'm no FreeBSD expert so correct me if I'm wrong.
question is: with the threading / memory allocation issues, does Wine have a chance to run right on 4.x? If not and lcms is up-to-date enough in 5.x then supporting the old 1.09 is probably not a priority.
Last time I checked there was an lcms version 1.13 in FreeBSD ports. -Hans
Le mer 24/11/2004 à 08:21, Hans Leidekker a écrit :
On Wednesday 24 November 2004 13:13, Francois Gouget wrote:
I do think it's a better solution. Just like it's better to let Wine compile even if the ALSA development libraries are not installed or obsolete, eventhough the resulting winealsa is going to be non-functional.
Agreed again about making it at least compile. But that's not the issue I was talking about. My concern is packagers like Gerald that may be building suboptimal packages because they don't use the latest development headers.
A packager has to target something (a distro, etc.). If your target has lcms 1.09 as standard, you can't require to update it for all users if the replacement version (1.13 or so) is not the standard one for that distro. Likewise, trying to force RH7.3 users to have alsa 1.0 or newer wouldn't work: they're using RH7.3 (rather than a newer version) for a reason, and it's most probably not so they have a lot of dependancies to update to use one more current package (Wine). [snip]
A related question is which version is normally shipped on FreeBSD (and I guess that's likely different for 4.x and 5.x). I guess that for 4.10 this is 1.09 but for 5.x it's probably a more recent version. Next
I don't think lcms is shipped with FreeBSD is it? It's in the ports collection. I'm no FreeBSD expert so correct me if I'm wrong.
I thought almost every lib used by Wine would be in ports then. I guess ports can be considered as part of FreeBSD from a dependancies point of view, it's the first place where FreeBSD users go fetch programs they don't currently have. Vincent
On Thursday 25 November 2004 02:08, Vincent Béron wrote:
A packager has to target something (a distro, etc.). If your target has
A packager could target a single distro and version, like you seem to do. A packager could also target multiple versions of the same distro (like Ivan does) and a packager could target multiple versions of multiple distro's and OS'es, like CodeWeavers seems to do.
lcms 1.09 as standard, you can't require to update it for all users if the replacement version (1.13 or so) is not the standard one for that distro.
No, I'm not requiring or forcing users to upgrade. I'm asking packagers (specifically those that target multiple distro's/OS'es or versions with a single package) to build with the most recent headers. Because that will result in the most functional Wine if recent lcms is available on a users' system. If lcms is not available Wine will degrade gracefully. If such a package was built with old headers users that actually have a recent lcms would not profit from it. See my point?
I thought almost every lib used by Wine would be in ports then. I guess ports can be considered as part of FreeBSD from a dependancies point of view, it's the first place where FreeBSD users go fetch programs they don't currently have.
Don't they automatically fetch the latest version in that case? Or is the ports collection versioned and tied to the FreeBSD main version? -Hans
On Thu, 25 Nov 2004, Hans Leidekker wrote:
lcms 1.09 as standard, you can't require to update it for all users if the replacement version (1.13 or so) is not the standard one for that distro. No, I'm not requiring or forcing users to upgrade. I'm asking packagers (specifically those that target multiple distro's/OS'es or versions with a single package) to build with the most recent headers. Because that will result in the most functional Wine if recent lcms is available on a users' system.
I actually think we are in violent agreement, even if it might not seem so at first sight. ;-) There seem to be two issues here: 1) You argue that packagers should use a recent version if possible, and I believe nobody objected. 2) On the other hand, there are also people compiling a FreeBSD port by themselves, or just using CVS Wine. For these, ALSA approach that Francois suggested seems to be a nice solution: if test -z "$ALSALIBS" then echo "*** Alsa not detected. The winealsa.drv.so driver will be a dummy." fi I certainly do not have a problem updating to a later version of lcms. However, I'm also getting support inquiries from those users described under item 2) above; that's why I'd appreciate a more gracious failure mode. ;-)
[FreeBSD Ports Collection] Don't they automatically fetch the latest version in that case? Or is the ports collection versioned and tied to the FreeBSD main version?
No, users won't automatically fetch the latest version of everything. The Ports Collection itself is not tied to the FreeBSD main version, but a surprisingly large number of users still does not seem to have cheap/reliable Internet access and the use of CD-ROMs (which contain the version of the Ports Collection at the time of the FreeBSD release) is wide spread. Users might update to a more recent version of a specific port like Wine, but not necessarily their whole collection of ports. Gerald
participants (4)
-
Francois Gouget -
Gerald Pfeifer -
Hans Leidekker -
Vincent Béron