libtool
[Top][All Lists]
Advanced

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

Re: sysroot support in libtool


From: Richard Purdie
Subject: Re: sysroot support in libtool
Date: Sun, 13 Apr 2008 15:59:26 +0100

Hi,

On Sun, 2008-04-13 at 08:21 -0400, Gary V. Vaughan wrote:
> On 13 Apr 2008, at 07:55, Richard Purdie wrote:
> > [1] Are there any plans to support sysroots with libtool?
> 
> No one is sending us bug reports or patches... so we don't even know
> there is a problem!

Ok, there are some fairly long running issues with OpenEmbedded and
libtool. I appreciate there has not been feedback to upstream about the
problems and this is entirely our fault. There are various reasons for
this:

* the person who integrated libtool into OE has moved onto other things
  and the knowledge for a lot of the "magic" was lost
* we're stuck on an old version of libtool (1.5.10) which we know you 
  won't be interested in bugs against
* this old version "works" and nobody has found the time for the 
  learning curve and debugging involved in upgrading

More recently a lot of things have changed for the better in OE and
we're striving for a clean logical build structure rather than hacks,
I've been one of the people trying to achieve this. One way we've done
this is embracing the sysroot options in gcc/binutils and getting
sysroot support into pkg-config.

So this leaves us with the problem of libtool. Why a problem?

Lets give an example of compiling some library which uses libtool and
autotools:

* We configure it with libdir=/usr/lib which is where the library will
be on the target system ultimately.
* Compile it using a gcc cross compiler and binutils which have been
configured with /somewhere/sysroot as the sysroot. This means they don't
look in /usr/lib and /usr/include, they look
in /somewhere/sysroot/usr/lib and /somewhere/sysroot/usr/include.
* We "make install DESTDIR=/someplace" and then build packages out
of /someplace
* We "make install DESTDIR=/somewhere/sysroot" which adds the library to
our sysroot environment so something using this lib can compile against
it.

The problem is this last step which installs .la files into our sysroot
which don't work. The issues we can have:

* The .la files say installed=yes but they're in the sysroot, not in
libdir.
* dependency_libs= can contain an expanded version of libdir. This is
wrong and we have to prepend the sysroot to this.
* libdir itself can be added to the search path for libraries which
finds things from /usr/lib on the host system - really bad when cross
compiling

To workaround these issues we sed the sysroot .la files to:

* change installed=yes to installed=no, it changes some of the logic
within libtool and breaks some assumptions about the files being in
libdir which helps.
* prepend sysroot to the appropriate parts of dependency_libs

and patch libtool to:

* remove the parts which add libdir into the search path
* cope with the installed=no logic and search both the sysroot and the
app being compiled

The above is the situation with 1.5.10. I've just tried a build with a
clean 2.2.2 and it broke with at least one of the problems mentioned
above, I don't know if all the above issues are still present but I
suspect they are meaning I need to forward port our hacks.

Whats the dream solution? We can set an environmental variable say
LIBTOOL_SYSROOT=/somewhere/sysroot and libtool would take this into
account exactly where needed and "just work". The .la files in our
sysroot would match those we install onto the target system.

Its possible things have changed and libtool has some mechanism to cope
with setups like this and if so please let me know what they are! If not
does the above illustrate the problem and is this something you'd be
prepared to help fix?

In the meantime I will try and get Poky/OE using a much more recent
libtool, patched enough so builds continue to work as described above.
Once we get a modern version working it will be much easier to test
patches and improvements in libtool and from what I've read, we should
see some performance improvements which would be most welcome. We don't
have patches to add sysroot support, just the sed hacks I've mentioned
but if you'd be interested in proper sysroot support that is something
we'd be interested in collaborating on.

Cheers,

Richard






reply via email to

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