Update: olepicture.c compile failure : `UserData' / `DGifOpen'

[Dan Kegel]

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