On Wed, Feb 27, 2008 at 12:58:15PM -0600, Nicolas Williams wrote:
> On Wed, Feb 27, 2008 at 10:49:52AM -0800, Danek Duvall wrote:
> > On Wed, Feb 27, 2008 at 12:00:32PM -0600, Nicolas Williams wrote:
> >
> > > On Wed, Feb 27, 2008 at 08:10:02PM +1300, Laszlo (Laca) Peter wrote:
> > > >
> > > > On Tue, 2008-02-26 at 17:47 -0600, Nicolas Williams wrote:
> > > > > BTW, I needed fix_elf_runpath() because libtool was somehow adding
> > > > > $SRC/lib/libsqlite3/... to the runpath of libtclsqlite3 (but not to
> > > > > libsqlite3). Don't ask me why; I don't know why.
> > > >
> > > > libtool adds the directories where it finds consumed libs to the
> > > > runpath, unless there's a .la file there that tells libtool where
> > > > the consumed library will end up eventually[1]. This is quite a
> > > > reasonable behaviour, if you think about it, it just happens to be
> > > > incompatible with the way SFW is built.
> > >
> > > That's not at all reasonable. Who builds where they install??
> >
> > Reasonable or not, if injecting a .la file into the source directory will
> > prevent libtool from adding crud to the runpath, perhaps it's an easy way
> > of getting what we want.
>
> I don't follow.
I could be completely misunderstanding what Laca meant, but what I took
from his statement was that:
- if there's no .la file for libtool to read, then it will stick various
crud paths in the RUNPATH of the executables it creates, including the
directories where its dependencies lie in the source
- if there *is* a .la file given to libtool, it will extract from it the
correct runpaths to insert into the executables it creates, and if one
of those paths is /usr/lib, it will be skipped.
Thus, if we can create a .la file that contains the correct data, and make
it available for libtool to use, there won't be any need for trickery to
get the right linker flags past libtool's nose, or to elfedit the crud
post-link.
But I could be wrong on all that.
Danek
