Rizwan Kassim wrote:
It seems that configure approves of vesrion 3.0.0 of libungif.so / gif_lib.h, but compile fails using 3.0.0. DGifOpen gif_lib.h 4.0.0 compiles correctly (even without updating libungif.so, but afaik thats pretty poor practice)
The gif_lib.h that configure approves of is labeled version 3.0 by Eric S Raymond.
(from gif_lib.h - 4.0.0 : GifFileType *DGifOpen(void *userPtr, InputFunc readFunc); /* new one
Interestingly, it seems that configure DOES show the failure during the test compile: ... configure:15599: checking for -lungif soname configure:15629: gcc -o conftest -g -O2 conftest.c -lungif >&5 /tmp/ccdg49tg.o: In function `main': /home/rizwank/wine/conftest.c:155: undefined reference to `DGifOpen' collect2: ld returned 1 exit status configure:15635: $? = 1 configure: failed program was:
<snip confdefs.h and a few more lines> configure:15738: result: libgif.so
Look in configure.ac for references to DGifOpen. You'll find WINE_GET_SONAME(ungif,DGifOpen) WINE_GET_SONAME(gif,DGifOpen) So Wine is looking in two places for DGifOpen, which explains perhaps why you're seeing the failure in the output of configure; one of the places it's looking doesn't have it. (Just a guess.)
As to who would know what's going on, try searching wine-patches for those lines, and you'll see two fairly recent patches, http://www.winehq.com/hypermail/wine-patches/2004/08/0045.html http://www.winehq.com/hypermail/wine-patches/2004/09/0252.html by Huy and Marcus. Since they've been playing with the code, maybe they can comment on the real problem you're having.
So, whats the next step? Should it be a critical error for configure? Should configure report the incorrect gif_lib.h (and old libungif)? I'm new enough to OSS projects that I'm not sure if I should : a) attempt to patch configure to report the error and stop the configure process
Yes, once you understand that section completely. We do want it to fail in configure rather than while compiling wine.
b) patch olepicture.c to stop using DGifOpen
I doubt it, but I haven't looked at those libraries
c) submit gif_lib.h to the tree in dlls/oleaut32
No, that would break encapsulation of the library.
This has been (partially) reported as Bug 1730 and 2437.
- Dan