Re: Gentlemen, start your engines...

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

Hans-Bernhard Br=F6ker wrote:
> Timoth=E9e Lecomte wrote:
>> Hans-Bernhard Br=F6ker wrote:
>>> Timoth=E9e Lecomte wrote:
>
>>>> The patch first fixes the build of gnuplot when libpdf and gd are=20
>>>> not 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 !
>
>> Hmm... You seem to be right. In fact, the important detail here is=20
>> that the user I've been discussing with has set the environment=20
>> variable GDLIB_CONFIG to his gdlib-config script before running=20
>> 'configure'.=20
>
> Wrong approach, IMHO.  If gdlib-config isn't in the PATH, that in=20
> itself implies a broken GD installation, or someone trying to use a GD=20
> that hasn't been installed yet.

I assume that some install in their home directory and don't have the=20
reflex to change the path... The user I told to was obviously using a=20
machine maintained by his university, so he had to install in his home=20
directory.

The idea to do it through GDLIB_CONFIG may be a little simpler than=20
changing the path from a developer point of view when you have several=20
installations of a given library (here gd) in different folders.

(I tried to declare GDLIB_CONFIG and PDFLIB_CONFIG as precious variables=20
and I think the result is quite good : they appear in ./configure=20
--help, so the situation becomes documented)

That is not release-critical, but it would be nice to fix.

>
> > I don't really know where he found the idea to do it, but there is
>> definitely the autoconf magic to do it. It's mentioned in the help=20
>> page of AC_PATH_PROG, and it's called a "precious variable",=20
>
> Not really.  The doc only "strongly suggests" that we should make it a=20
> precious variable, not that autoconf doest that by itself --- and we=20
> don't do that.
>
>> 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=20
>> linked 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
>
> And I have a feeling that Mr. Boutell (or GNU gettext/iconv=20
> autoconfigury) did this on purpose, for a very good reason.  The=20
> problem with iconv is that terribly often, there will be two libraries=20
> under this name on non-GNU Unix box: GNU's version, and the vendor's. =20
> And it's very important that you get exactly the one you want.  Using=20
> the -L/-l search mechanism would be fatal in that case.
>
> Anyway: specifying the library name full can't cause any problem. =20
> It's not a bug.

You convinced me. I guess I was mislead (again !) by my google searchs=20
on this problem, where I read that people had to set "LIBS=3D-liconv" by=20
hand. It's obviously a workaround but did hide the real problem.


>
>> But look carefully at the patch: as it was written before, the=20
>> contents of 'gdlib-config --libs' was added to TERMLIBS after the=20
>> checks, so gnuplot was effectively linked against all those libs.=20
>
> I'm aware of that part, and also that changing it would fix the OP's=20
> problem.  The nasty question is: what will that change do to *other*=20
> people's configurations?
>
I can't see a situation where taking 'gdlib-config --libs' into account=20
would change anything. Do you have an example ?

Timoth=E9e