Re: Gentlemen, start your engines...

[<br...@ph...>]

Timoth=E9e Lecomte wrote:

> The patch first fixes the build of gnuplot when libpdf and gd are n=
ot=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 "gdlib-c=
onfig".

> 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 =
too,=20
> or undefined references are obtained. The first offender here is=
=20
> gdlib-config itself which doesn't report correctly '-liconv' but a =
full=20
> 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* wa=
nt=20
to trust the -l option to find the right copy of.

> script would not catch it since it doesn't take 'gdlib-config --lib=
s'=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 on=
),=20
GD was easily the single most tricky external library we ever linked=
=20
against.  E.g. on some platforms, one *must* link with all the=20
underlying libraries explicitly, on others, it's basically forbidden =
to=20
try --- depending on exotica like whether a platform's shared librari=
es=20
dynamically link to other shared libraries.

> Without gd fixed, LIBS=3D'-liconv' had to be used when calling 'con=
figure'.

This looks wrong. This can only really fail if libiconv was moved awa=
y=20
since its position was hard-coded into gdlib-config.  In that case, t=
he=20
GD installation has to be considered FUBAR.  It has to be reinstalled=
.