Re: Gentlemen, start your engines...

[<tim...@en...>]

Hans-Bernhard Br=F6ker wrote:
> Timoth=E9e Lecomte wrote:
>
>> The patch first fixes the build of gnuplot when libpdf and gd are not=20
>> installed in standard directories. In those situations, whereas=20
>> configure was checking for the position of the gdlib-config and=20
>> pdflib-config scripts, it did not use the result !
>
> I don't think your analysis of this is correct.  GDLIB_CONFIG is=20
> searched in the same $PATH the shell will search it in.  So if=20
> AC_CHECK_PROG found it, so will the shell if you run by just=20
> "gdlib-config".
Hmm... You seem to be right. In fact, the important detail here is that=20
the user I've been discussing with has set the environment variable=20
GDLIB_CONFIG to his gdlib-config script before running 'configure'. I=20
don't really know where he found the idea to do it, but there is=20
definitely the autoconf magic to do it. It's mentioned in the help page=20
of AC_PATH_PROG, and it's called a "precious variable", as a variable=20
that can also be set by the environment, not only by a test. Maybe we=20
should declare it with AC_ARG_VAR to remove all possible ambiguity.

>
>> Moreover, there is a problem with gd on systems where GNU libiconv is=20
>> installed. In this case, gnuplot has to be linked against libiconv=20
>> too, or undefined references are obtained. The first offender here is=20
>> gdlib-config itself which doesn't report correctly '-liconv' but a=20
>> full path to libiconv.so.=20
>
> I don't think that's actually wrong.  Iconv is a massively overloaded=20
> name for a library --- it may well be one library that you *don't*=20
> want to trust the -l option to find the right copy of.

I'm not disputing the fact that there may be multiple copies, I'm=20
disputing the fact that gdlib-config reports the following, when linked=20
to GNU libiconv:

    /home/research/csmkchan/lib/libiconv.so=20
-Wl,-rpath,/home/research/csmkchan/lib/

whereas I think it should report:

    -L/home/research/csmkchan/lib -liconv -R/home/research/csmkchan/lib

(for details, gd uses LIBICONV instead of LTLIBICONV in its configure=20
script, see=20
http://www.gnu.org/software/gettext/manual/html_node/gettext_189.html
that's probably wrong since gd is precisely built as a libtool library).

>
>> script would not catch it since it doesn't take 'gdlib-config --libs'=20
>> into account. The attached patch fixes this issue too.
>
> I've learned to mistrust any obvious or easy changes to the GD=20
> configury.  Before you added wx (and all the other libs it depends=20
> on), GD was easily the single most tricky external library we ever=20
> linked against.  E.g. on some platforms, one *must* link with all the=20
> underlying libraries explicitly, on others, it's basically forbidden=20
> to try --- depending on exotica like whether a platform's shared=20
> libraries dynamically link to other shared libraries.
I agree there may be some strange things going on there...

But look carefully at the patch: as it was written before, the contents=20
of 'gdlib-config --libs' was added to TERMLIBS after the checks, so=20
gnuplot was effectively linked against all those libs. _But_ it was=20
added _after_ the checks for gdImageCreate and friends. _This_ is the=20
bug. On IRC, I checked the config.log files of "Michael" who just posted=20
to comp.graphics.apps.gnuplot under the thread "Installing 4.1", and he=20
precisely got caught by this: 'gdlib-config --libs' was asking to link=20
against libiconv, but as this wasn't added for gnuplot checks, he=20
eventually ended up with gd not found and the errors mentioned in the=20
thread.

Best regards,

Timoth=E9e Lecomte