olepicture.c compile failure : "structure has no member named `UserData', implicit declaration of function `DGifOpen'"
This has been reported as Bugzilla 1730. " olepicture.c: In function `_gif_inputfunc': olepicture.c:834: structure has no member named `UserData' olepicture.c: In function `OLEPictureImpl_Load': olepicture.c:923: warning: implicit declaration of function `DGifOpen' olepicture.c:923: warning: assignment makes pointer from integer without a cast make[2]: *** [olepicture.o] Error 1 " configure, apparently, doesn't check that both libgif.so and libungif.so are the correct versions. This was with latest CVS 2005-01-15, in /wine/dlls/oleaut32 Some slackware and debian installs that I've found have : /usr/lib/libgif.so -> libungif.so.3.0.0 /usr/lib/libungif.so -> libungif.so.3.0.0 libungif.so.4.1.0 was available, however. Running: ln -s /usr/lib/libungif.so.4.1.0 libungif.so ln -s /usr/lib/libungif.so.4.1.0 libgif.so in the wine/dlls/oleaut32 directory fixes the compile. I've added this fix to the (Unconfirmed) bug. Any input -- whats my next step? -- Thank you, Rizwan Kassim
On Wed, Jan 19, 2005 at 05:48:13PM -0800, Rizwan Kassim wrote:
This has been reported as Bugzilla 1730. " olepicture.c: In function `_gif_inputfunc': olepicture.c:834: structure has no member named `UserData' olepicture.c: In function `OLEPictureImpl_Load': olepicture.c:923: warning: implicit declaration of function `DGifOpen' olepicture.c:923: warning: assignment makes pointer from integer without a cast make[2]: *** [olepicture.o] Error 1 "
configure, apparently, doesn't check that both libgif.so and libungif.so are the correct versions. This was with latest CVS 2005-01-15, in /wine/dlls/oleaut32 Some slackware and debian installs that I've found have : /usr/lib/libgif.so -> libungif.so.3.0.0 /usr/lib/libungif.so -> libungif.so.3.0.0
libungif.so.4.1.0 was available, however. Running: ln -s /usr/lib/libungif.so.4.1.0 libungif.so ln -s /usr/lib/libungif.so.4.1.0 libgif.so in the wine/dlls/oleaut32 directory fixes the compile.
I've added this fix to the (Unconfirmed) bug. Any input -- whats my next step?
Both have conflicting header files apparently. Only the .so for the one with gif_lib.h header should be installed. Ciao, Marcus
An update to my previous posting: Steps: 1) Install debian-stable-latest. 2) get Wine directly off the CVS server (version used Jan 31 2005 22:52p PST) 3) configure, make depend, make. The following results in dlls/oleaut32: gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_OLEAUT32_ -DCOM_NO_WINDOWS_H -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o olepicture.o olepicture.c In file included from /usr/include/jpeglib.h:24, from olepicture.c:85: /usr/include/jconfig.h:12: warning: `HAVE_STDLIB_H' redefined ../../include/config.h:541: warning: this is the location of the previous definition olepicture.c:898: `DGifOpen' undeclared here (not in a function) olepicture.c:898: warning: type defaults to `int' in declaration of `pDGifOpen' olepicture.c: In function `_gif_inputfunc': olepicture.c:930: structure has no member named `UserData' olepicture.c: In function `OLEPictureImpl_Load': olepicture.c:1040: called object is not a function olepicture.c:1070: structure has no member named `Function' olepicture.c:1018: warning: `gif' might be used uninitialized in this function make[2]: *** [olepicture.o] Error 1 jconfig.h just seems like a "bad citizen" - #undef HAVE_STDLIB_H before it redefines it works fine. Of greater concern is the issues with DGifOpen. 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: config.log: configure:15570: test -s conftest configure:15573: $? = 0 configure:15590: result: libjpeg.so.62 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 ======= Now, looking through config.log, I noticed a number of various errors that didn't lead to compile errors in wine, but this one did. (its easy to quelch the error, copy a new lib_gif.h to dlls/oleaut32. I'd assume that new libraries would be smart; while oleauto32/tests doesn't report any errors with using 4.0 of lib_gif.h and 3.0 of libungif.so, it doesn't seem to actually test any of the olepicture calls just yet). 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 b) patch olepicture.c to stop using DGifOpen c) submit gif_lib.h to the tree in dlls/oleaut32 This has been (partially) reported as Bug 1730 and 2437. Any input would be totally appreciated! Rizwan (outputs of configure, make depend, make and make test, as well as config.log and config.status are available at http://www.geekymedia.com/twiki/bin/view.cgi/WineDev/LugWine ) -- Thank you, Rizwan Kassim Octal is the way God meant programmers to count - the thumbs are parity bits.
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 -- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html
participants (3)
-
Dan Kegel -
Marcus Meissner -
Rizwan Kassim