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 <g...@gnu.org> > > 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 (g...@gnu.org) _______________________________________________ http://lists.gnu.org/mailman/listinfo/libtool