Re: libtool adds an annoying -L/usr/lib in link command

[Gary V. Vaughan]

Hi Christian,

[[Libtool list added back in to Cc:]]

On 9 Jun 2010, at 21:17, christian caremoli wrote:
> 2010/6/9 Gary V. Vaughan <address@hidden>
> > Most likely your libhdf.la has -L/usr/libs in its dependency_libs entry.  
> > You can fix that by editing the libhdf.la file to pass the library name by 
> > its full path, or by adjusting the install process of libhdf not to record 
> > -L/usr/libs there.
> >
> > dependency_libs in libhdf5.la does not contain -L/usr/lib. I have already 
> > checked that.
> > dependency_libs=' -lpthread -lz -lm'
> 
> Are you using a stock libtool?  Or a patched version packaged by your OS 
> vendor?
> I use a libtool that I have installed from a 2.2.8 tar.gz downloaded from 
> libtool site 
> I use this libtool with automake
> 
> Have you looked along the entire dependency tree of the libraries you pass on 
> the link line to see whether one of the .la files libtool finds contains a 
> -L/usr/lib?  Or with ldd(1)/objdump(1) or equivalent to see whether one of 
> the libraries along that path has /usr/lib in it's RPATH?
> 
> -lhdf5 has a .la file but it has no rpath in libhdf5.so
>  -lz has no .la file and no rpath
> -lm has no .la and no rpath
> -lpthread has no .la and I can't find if it has rpath
> -lvtkCommon has no rpath

Okay, thanks for checking.

> While it's possible that libtool is adding the -L/usr/lib spuriously, when 
> this has happened to other users it has always turned out to be due to the 
> dependencies.
> 
> If you have root access to the machine in question, you can always rename the 
> .la files on your machine temporarily to hide them from libtool to see 
> whether the link works then... and if so, it's just a matter of tracking down 
> which .la file has the -L/usr/lib entry inside when you've put them back 
> again.
> 
> Hope that helps.
> I  have tried to hide libhdf5.la. The link works well with that modification 
> but I have no -L/usr/lib in dependencies.

As in, when you hide libhdf5.la, the spurious -L disappears and everything 
behaves as you would expect?  In that case, please send me libhdf5.la and I'll 
see if I can figure out what is going wrong.

> Moreover it's not really -L/usr/lib that is
> added by libtool, it's -L/usr/lib/gcc/x86_64-linux-gnu/4.3.2/../../../../lib

Ugh.  Maybe libtool is somehow pulling this out of your gcc specfile? (gcc 
-dumpspecs might be enlightening?).

It's at least a couple of years since I last look at any of the funky libtool 
code that digs around in linker paths and I barely remember what it's for or 
how it works. It would also help me if you rerun your failing libtool link line 
with '--debug' added, and send me copies of the parts of the output that are 
apparently adding the spurious -L flag (along with plenty of context).

> I have tried the last libtool version 2.2.8 because I had another problem 
> with the debian libtool 1.5.6 during install (libtool adds -L/usr/lib again).
> There is difference between my installation and the debian installation : 
> link_all_deplibs=no instead of link_all_deplibs=unknown
> If I modify my libtool with link_all_deplibs=no the link works well but now 
> it's the install that does not work (debian libtool and my libtool
> give same results)

Looks like that was a red herring then.

Cheers,
-- 
Gary V. Vaughan (address@hidden)