[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Gary V. Vaughan
Subject: Re: libtool adds an annoying -L/usr/lib in link command
Date: Thu, 10 Jun 2010 02:56:02 +0700

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 has -L/usr/libs in its dependency_libs entry.  
> > > You can fix that by editing the 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 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
> >  -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 The link works well with that 
> > modification but I have no -L/usr/lib in dependencies.
> As in, when you hide, the spurious -L disappears and everything 
> behaves as you would expect?  In that case, please send me 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 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 

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 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.

Gary V. Vaughan (address@hidden)        

reply via email to

[Prev in Thread] Current Thread [Next in Thread]