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

[Gary V. Vaughan]

Hi Christian,

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

Please don't top post on technical lists, but thanks for not sending the long 
logs to the list :)

On 9 Jun 2010, at 23:10, christian caremoli wrote:
> 2010/6/9 Gary V. Vaughan <address@hidden>
> 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 attached the libhdf5.la file 
> Here is the variable compiler_lib_search_path from libtool 
> "-L/usr/lib/gcc/x86_64-linux-gnu/4.3.2 -L/usr/lib/gcc/x86_64-linux-gnu/4.3.2 
> -L/usr/lib/gcc/x86_64-linux-gnu/4.3.2/../../../../lib -L/lib/../lib 
> -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-linux-gnu/4.3.2/../../.."
> probably from compiler g++
> I have attached the result of execution with --debug (listing) the -L appears 
> between line 2778 and line 2930.

I'm stuck at analysing this anymore until I have access to a Linux machine 
again.  On my mac,
$compiler_lib_search_dirs and $compiler_lib_search_path are always empty, but 
it seems like the configure time code in _LT_SYS_HIDDEN_DEPS is doing the right 
thing by collecting the various library flags and libraries from the output of 
$output_verbose_link_cmd.

I'm not sure whether your problem is that the $compiler_lib_search_xxx 
variables should not contain those paths at all (you can see whether setting 
them to empty in each tag of your libtool script allows libtool to work 
properly for you), or whether the logic in ltmain.sh is misusing those values 
for some reason.

I'll be happy if someone else can jump in and help me out here.  Otherwise I'll 
try to take another look in a few days when I'm next on Linux.

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