Re: gnuplot-4.0.0 fails to link on Digital UNIX V4.0E

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

On Sunday 25 April 2004 12:56 pm, Hans-Bernhard Broeker wrote:
> On Sat, 24 Apr 2004, Bernhard Simon wrote:
> > Environment: Digital UNIX V4.0E, cc, gnuplot-4.0.0
> >
> >  * cc -std1 -O -o gnuplot alloc.o ... version.o \
> >  -lz -lpng -lm 
     ^^^^^^^^^^^^^                                                             
> >    ld:
> >    Unresolved:
> >    deflate
> >    deflateEnd
> >    inflateReset
> >    crc32
> >    deflateReset
> >    deflateInit2_
> >    [ Fix: link with ... -lpng -lz -lm ]
                            ^^^^^^^^^^^^^
>
> That's not the right way of fixing this, of course.  The actual
> bug is in configure.in, where linking against -lgd and -lpng is
> tested and the variables used in the link command are set up.
>
> Ethan: I'm CCing you on this because if memory serves, it was you who
> claimed that the tests in their current shape are the only way to get
> this to work on some platforms.  

I have vague recollections of saying that, but the only thing I can
find in the mailing list archive (from Jan 2003) is a slightly 
different issue. I was making the point that (at least under linux) 
if ./configure tests for libpng and finds it, it will be finding the 
most current installed version.  But this version may not
match the one that, say, libgd was linked against.  In this case you get
incompatibility warnings at link time.  So I was arguing against 
specifying "-lpng -lz" explicitly if libgd was already being included.
I honestly do not know if these are ever fatal errors, but they certainly
appear in the  make output.  I am, for instance, currently getting such
warnings because libgd and libpdf were themselves built against different
versions of libpng:
	/usr/bin/ld: warning: libpng.so.2, needed by /usr/lib/gcc-lib/i586-mandrake-linux-gnu/3.3.1/../../../libpdf.so, may conflict with libpng.so.3
This one has caused me no problems so far, and I could get rid of it by
rebuilding libpdf. 

Regardless of all that, the current report looks to me to be a different
issue.  He had to change the order of the libraries in the link statement.
Apparently ./configure places them in the wrong order.
If I ever had a reason for wanting -lz to come before -lpng I can no longer
remember what it might have been.  So if moving the tests on libz to after
the png tests fixes the problem, I have no objection (but we should test
it first, of course).

> Can we please clean this up soon?

I have not done development under DU for a couple of years now.
My recollection of little tricks and gotchas is fading.  But, as I say,
the current version 4 ./configure file does work for me under DU 4.0D
That may be because I am linking against libgd also. Maybe.


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