Re: Gentlemen, start your engines...

[Lars H. <lhe...@us...>]

Timoth?e Lecomte writes:
[...] 
> I'm not disputing the fact that there may be multiple copies, I'm 
> disputing the fact that gdlib-config reports the following, when linked 
> to GNU libiconv:
> 
>     /home/research/csmkchan/lib/libiconv.so 
> -Wl,-rpath,/home/research/csmkchan/lib/

 This looks wrong. Is it really on two lines? If the .so can be linked
 explicitly, and I'm not even sure this can be done, the rpath directive
 is surely not needed.

> 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 
> script, see 
> 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).

 I will check this out and fix it if necessary.

> But look carefully at the patch: as it was written before, the contents 
> of 'gdlib-config --libs' was added to TERMLIBS after the checks, so 
> gnuplot was effectively linked against all those libs. _But_ it was 
> added _after_ the checks for gdImageCreate and friends. _This_ is the 
> bug.

 This seems logically correct to me: the libs are added after the
 (successful) check.

>      On IRC, I checked the config.log files of "Michael" who just posted 
> to comp.graphics.apps.gnuplot under the thread "Installing 4.1", and he 
> precisely got caught by this: 'gdlib-config --libs' was asking to link 
> against libiconv, but as this wasn't added for gnuplot checks, he 
> eventually ended up with gd not found and the errors mentioned in the 
> thread.

 I'll see if I can find this. Gnuplot's configure uses the library's
 config script precisely to keep complexity down so that it doesn't
 need to cover indirect library dependencies.