as I already discovered when I built the DJGPP binary package, and some
users have begun discovering on other Unix platforms, the way our
configure script handles -lz is broken in several interesting ways.
Here's a crucial snippet from config.log (wrapped around manually)
on a Linux box:
configure:10544: checking for gdImagePng in -lgd
configure:10574: gcc -o conftest -g -O2 -I/usr/X11R6/include \
conftest.c -lgd -lm -ljpeg -lfreetype -lpng >&5
configure:10606: result: yes
Note the absence of -lz in that test link. It works nevertheless, but
only because Linux has internal dependency tracking for shared libraries,
so -lpng can instruct the linker to pull in -lz.
On platforms not supporting that trick, particularly those using static
libraries, this link will fail and thus the PNG part of the GD lib will
not be built --- you get the old PNG driver instead.
I thought it was Ethan who did this, but after discussing this in private
mail, I went back to check, and it seems it's Lars who last worked on this
I'm tempted to just check in the fix I used for the DJGPP build, but am a
little wary of interfering with the rather tricky way these tests are
written (caching and restoring the state of autoconf internal variable
like LIBS, e.g.).
One more note: the way we use gdlib-config to override the $libgd_LIBS
*after* running the tests will almost certainly not achieve what's meant
to, either. In particular, it doesn't correct the results of failed link
tests caused by failure to use it.
Hans-Bernhard Broeker (broeker@...)
Even if all the snow were burnt, ashes would remain.
Get latest updates about Open Source Projects, Conferences and News.