Re: Troubles with recent GD on Win32

[Ethan M. <merritt@u.washington.edu>]

As best as I can make out by inspection of the libgd source, the
difficulty arises not from anything on our end, but from the 
environment at the time the libgd dll was built. 

The fonts are declared extern, or not, based on the following
hack in gd.h.  (This is not new to 2.0.22, by the way; it was
introduced several versions back)

/* Do the DLL dance: dllexport when building the DLL,
        dllimport when importing from it, nothing when
        not on Silly Silly Windows (tm Aardman Productions). */

/* 2.0.20: for headers */
#ifdef BGDWIN32
#define BGD_EXPORT __declspec(dllexport)
#else
#ifdef WIN32
#define BGD_EXPORT __declspec(dllimport)
#else
/* 2.0.19: should be 'extern', especially for font data pointers */
#define BGD_EXPORT extern
#endif /* WIN32 */
#endif /* BGDWIN32 */


So in a non-windows environment they are always declared extern,
and everything works.  In windows - well, I don't know.  Someone
who actually builds under windows can tell better than I.

My impression from reading the release notes is that this issue is one
that bit people building the dlls under windows, and the new routines
were added to bypass the problem.


On Monday 05 April 2004 10:11 am, Hans-Bernhard Broeker wrote:
> Hi, everyone,
>
> looks like user just found a gnuplot build problem with the latest
> version of GD used on Win32/MSVC++. The gdFontPtr variables for the 5
> builtin fonts of the gd library came back as undefined externals. 
> Looking into this revealed the following:
>
> 1) gd.trm (and gif.trm, too...) contains our own private "extern"
> declarations rather than #include's of the corresponding headerfiles
> provided by GD.  Does any of us see a reason we shouldn't just #include
> those?

I don't think that will fix it, though I could be wrong.  The problem is that
the dll is not exporting it properly in the first place.

> 2) Tom Boutell added getter functions for those globals to his library,
> specifically for the purpose of fixing problems of Win32 DLLs, but
> without going into details about those problems.  Does this ring any
> bell to any of us? Should we bother and patch gnuplot to use these (and
> introduce yet another version check on GD for this)?  Or should we just
> put a note into INSTALL that GD version 2.0.22 won't work with gnuplot?

I'm just going by inspection of the libgd source files, but so far as I can
see nothing changed in 2.0.22.   I conclude that this has been a problem
all along if the dll was not built correctly.  Rather than fixing the problem
directly, 2.0.22 adds these separate functions as a work-around that
bypasses the question of whether the font pointers are correctly exported.

-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195