Re: libtool rearranging library paths

[Ralf Wildenhues]

* Christopher Hulbert wrote on Fri, Dec 02, 2005 at 05:31:52PM CET:
> > On another note, why does libtool add an entire static archive (.a) if
> > it wasn't created with libtool?  I did an nm on a convenience library
> > and it had a .a stuck in there and nm complained that it didn't know
> > what file type that was.  It was also missing the symbols from inside
> > that archive (the objects were in an archive in an archive).  I think
> > I also did this for a shared object and got the same results.
> 
> Sorry, should have mentioned that it happens when putting the library
> in the automake _LIBADD variable.  It's friday right? :)

D'oh.  I know what you mean.  Don't use
  libtool --mode=link $CC -o libfoo.la foo.lo libbar.a

but instead use
  libtool --mode=link $CC -o libfoo.la foo.lo -L. -lbar

which is more portable.  Well, not really, but at least it does what
you'd expect from libtool: not add libbar to either the archive nor the
shared library, but add its name in the dependency_libs entry of
libfoo.la, so that programs linked against libfoo.la will pick it up.

Sure this may be regarded as a libtool limitation.  Just as putting a
/path/to/shlib.so right on the command line.  Both is bad: on some
systems, the latter will hardcode the path into the output -- not really
what you'd expect in any case.

Cheers,
Ralf