Re: Issue with libtool when cross-compiling

2010-02-12 Thread Nick Bowler
On 16:34 Fri 12 Feb , Thomas Petazzoni wrote:
 Hello,
 
 I'm a contributor to the Buildroot project (http://www.buildroot.org),
 a build system for embedded Linux systems. We integrate many packages
 in order to ease their cross-compilation.
 
 I'm facing an issue with several packages where libtool wants to link
 against libraries of the host (in /usr/lib), and I don't know what
 is happening. It is very likely a problem in the environment variables
 or the options we pass to the configure script, but I'm unable to find
 where the problem is, and thought that libtool experts might have an
 idea on what's going on.

This happens when doing a DESTDIR install when libtool libraries link
against other libtool libraries in the same package.  The compiled
libraries are completely correct, but 'make install' destroys them.

Unfortunately, the only solution that I'm aware of is to avoid using
'make install' and to copy the files from .libs manually :(

-- 
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)


___
http://lists.gnu.org/mailman/listinfo/libtool


Re: Issue with libtool when cross-compiling

2010-02-12 Thread Richard Purdie
On Fri, 2010-02-12 at 16:34 +0100, Thomas Petazzoni wrote:
 I'm a contributor to the Buildroot project (http://www.buildroot.org),
 a build system for embedded Linux systems. We integrate many packages
 in order to ease their cross-compilation.
 
 I'm facing an issue with several packages where libtool wants to link
 against libraries of the host (in /usr/lib), and I don't know what
 is happening. It is very likely a problem in the environment variables
 or the options we pass to the configure script, but I'm unable to find
 where the problem is, and thought that libtool experts might have an
 idea on what's going on.

libtool has known cross compile issues and doesn't get on well with
sysroots. 

I maintain the OpenEmbedded libtool patch set which at least lets us
work around the worst libtool issues. The main patch is:

http://git.pokylinux.org/cgit.cgi/poky/tree/meta/packages/libtool/libtool-2.2.6/cross_compile.patch

and there is a bugfix I've been meaning to look at in more detail which
became neccessary with recent autoconf/automake versions:

http://git.pokylinux.org/cgit.cgi/poky/tree/meta/packages/libtool/libtool-2.2.6/trailingslash.patch

where a trailing slash on paths causes a string comparison to fail. We
also apply: 

http://git.pokylinux.org/cgit.cgi/poky/tree/meta/packages/libtool/libtool-2.2.6/prefix.patch

which renames libtool and allows us to easily tell when the wrong
(unpatched) libtool is being used.

There are other workarounds we have to apply after installing packages,
particularly modifying the .la files to be uninstalled to get the
sysroot to work properly. I'd love to teach libtool about sysroots and
make it work properly but as yet have never had the time to look into
it.

Cheers,

Richard




___
http://lists.gnu.org/mailman/listinfo/libtool


Re: Issue with libtool when cross-compiling

2010-02-12 Thread Thomas Petazzoni
Hello Richard,

Thanks for your input!

On Fri, 12 Feb 2010 16:00:49 +
Richard Purdie rpur...@rpsys.net wrote:

 libtool has known cross compile issues and doesn't get on well with
 sysroots. 
 
 I maintain the OpenEmbedded libtool patch set which at least lets us
 work around the worst libtool issues. The main patch is:
 
 http://git.pokylinux.org/cgit.cgi/poky/tree/meta/packages/libtool/libtool-2.2.6/cross_compile.patch
 
 and there is a bugfix I've been meaning to look at in more detail
 which became neccessary with recent autoconf/automake versions:
 
 http://git.pokylinux.org/cgit.cgi/poky/tree/meta/packages/libtool/libtool-2.2.6/trailingslash.patch
 
 where a trailing slash on paths causes a string comparison to fail. We
 also apply: 
 
 http://git.pokylinux.org/cgit.cgi/poky/tree/meta/packages/libtool/libtool-2.2.6/prefix.patch
 
 which renames libtool and allows us to easily tell when the wrong
 (unpatched) libtool is being used.

I suppose you apply these modifications to a libtool that you are
compiling. However, libtool is typically already embedded in each
upstream tarball. Do you run autoreconf on all packages, so that a
newer libtool script gets generated (autoreconf-ing each package takes a
lot of time) ? Do you somehow replace the provided libtool by a fixed
one ?

Moreover, some packages use libtool 1.5.x and some newer packages use
libtool 2.2.x. How do you handle this version difference ?

 There are other workarounds we have to apply after installing
 packages, particularly modifying the .la files to be uninstalled to
 get the sysroot to work properly.

« to be uninstalled » ?

In Buildroot, we already modify the libdir='' in all the .la files so
that they refer to the sysroot instead of /usr/lib.

If possible, could you point me to the location in OpenEmbedded where
libtool is handled ? I already had a look at your patches, but don't
understand how you re-generate the libtool script inside the different
upstream packages.

Thanks!

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


___
http://lists.gnu.org/mailman/listinfo/libtool


Re: Issue with libtool when cross-compiling

2010-02-12 Thread Richard Purdie
On Fri, 2010-02-12 at 19:34 +0100, Thomas Petazzoni wrote:
 I suppose you apply these modifications to a libtool that you are
 compiling. However, libtool is typically already embedded in each
 upstream tarball. Do you run autoreconf on all packages, so that a
 newer libtool script gets generated (autoreconf-ing each package takes a
 lot of time) ? Do you somehow replace the provided libtool by a fixed
 one ?
 
 Moreover, some packages use libtool 1.5.x and some newer packages use
 libtool 2.2.x. How do you handle this version difference ?

Due to exactly this kind of problem OpenEmbedded generally autoreconfs
all sources.

  There are other workarounds we have to apply after installing
  packages, particularly modifying the .la files to be uninstalled to
  get the sysroot to work properly.
 
 « to be uninstalled » ?

Set installed=no in the .la files.

 In Buildroot, we already modify the libdir='' in all the .la files so
 that they refer to the sysroot instead of /usr/lib.

We change the dependency_libs line. The libdir line refers to the final
install location and /usr/lib is in fact valid there.

 If possible, could you point me to the location in OpenEmbedded where
 libtool is handled ? I already had a look at your patches, but don't
 understand how you re-generate the libtool script inside the different
 upstream packages.

meta/classes/autoconf.bbclass has the autoreconf code

meta/classes/base.bbclass has the .la file manipulation.

What I find frustrating is that buildroot is playing catchup to OE these
days. By the time you make all the improvements to buildroot, you end up
with OE.

What would it take to get the buildroot people using OE and focusing
effort to new problems, not ones already at least partially solved?

I'd love to see a kconfig wrapper to OE for example...

Cheers,

Richard





___
http://lists.gnu.org/mailman/listinfo/libtool