configure handling of -lz is fishy

[Hans-Bernhard B. <br...@ph...>]

Hi, everybody,

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
(December 2002).  

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 (br...@ph...)
Even if all the snow were burnt, ashes would remain.