Re: Issue with libtool when cross-compiling
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
Re: Issue with libtool when cross-compiling
Hello Richard, Thanks for your input! On Fri, 12 Feb 2010 16:00:49 + Richard Purdie 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
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
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
Issue with libtool when cross-compiling
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. Note that I'm building for ARM with the CodeSourcery toolchain. I'm building in a Debian stable chroot, with a very minimal set of packages installed (libtool is not installed on the host, for example). The example I've taken is the cross-compilation of libglib 2.22.4. It fails at the install step with the following error message : make[7]: Leaving directory `/home/test/brtest-ext/build/libglib2-2.22.4/gmodule' libtool: install: warning: relinking `libgmodule-2.0.la' libtool: install: (cd /home/test/brtest-ext/build/libglib2-2.22.4/gmodule; /bin/sh /home/test/brtest-ext/build/libglib2-2.22.4/libtool --tag CC --mode=relink /home/test/arm-2009q3//bin/arm-none-linux-gnueabi-gcc -Os -pipe -Os -mabi=aapcs-linux -msoft-float -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 --sysroot /home/test/brtest-ext/staging/ -Os -pipe -Os -mabi=aapcs-linux -msoft-float -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 --sysroot /home/test/brtest-ext/staging/ -Wall -Wl,--export-dynamic -version-info 2200:4:2200 -export-dynamic --sysroot /home/test/brtest-ext/staging/ -o libgmodule-2.0.la -rpath /usr/lib gmodule.lo -ldl ../glib/libglib-2.0.la -lintl -inst-prefix-dir /home/test/brtest-ext/target) libtool: relink: /home/test/arm-2009q3//bin/arm-none-linux-gnueabi-gcc -Os -pipe -Os -mabi=aapcs-linux -msoft-float -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 --sysroot /home/test/brtest-ext/staging/ -shared .libs/gmodule.o -Wl,-rpath -Wl,/home/test/brtest-ext/staging/usr/lib -ldl -L/home/test/brtest-ext/target/usr/lib -L/usr/lib -lglib-2.0 -L/home/test/brtest-ext/staging/usr/lib -L/home/test/brtest-ext/target/home/test/brtest-ext/staging/usr/lib -lintl -lc -mabi=aapcs-linux -msoft-float -mabi=aapcs-linux -msoft-float -Wl,--export-dynamic -Wl,-soname -Wl,libgmodule-2.0.so.0 -o .libs/libgmodule-2.0.so.0.2200.4 /home/test/arm-2009q3/bin/../lib/gcc/arm-none-linux-gnueabi/4.4.1/../../../../arm-none-linux-gnueabi/bin/ld: warning: library search path "/usr/lib" is unsafe for cross-compilation /usr/lib/libdl.so: file not recognized: File format not recognized collect2: ld returned 1 exit status libtool: install: error: relink `libgmodule-2.0.la' with the above command before installing it make[6]: *** [install-libLTLIBRARIES] Error 1 So it fails because -L/usr/lib was passed to the linker. However, I haven't passed -L/usr/lib to the configure script. See the ./configure line below (split on several lines for readability) PATH="/home/test/brtest-ext/host/bin:/home/test/brtest-ext/host/usr/bin:/home/test/brtest-ext/host/usr/sbin/:/home/test/brtest-ext/toolchain/bin:/home/test/arm-2009q3//bin:/usr/local/bin:/usr/bin:/bin:/usr/games" AR="/home/test/arm-2009q3//bin/arm-none-linux-gnueabi-ar" AS="/home/test/arm-2009q3//bin/arm-none-linux-gnueabi-as" LD="/home/test/arm-2009q3//bin/arm-none-linux-gnueabi-ld" NM="/home/test/arm-2009q3//bin/arm-none-linux-gnueabi-nm" CC="/home/test/arm-2009q3//bin/arm-none-linux-gnueabi-gcc -Os -pipe -Os -mabi=aapcs-linux -msoft-float -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 --sysroot /home/test/brtest-ext/staging/" GCC="/home/test/arm-2009q3//bin/arm-none-linux-gnueabi-gcc -Os -pipe -Os -mabi=aapcs-linux -msoft-float -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 --sysroot /home/test/brtest-ext/staging/" CPP="/home/test/arm-2009q3//bin/arm-none-linux-gnueabi-cpp -Os -pipe -Os -mabi=aapcs-linux -msoft-float -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 --sysroot /home/test/brtest-ext/staging/" CXX="/home/test/arm-2009q3//bin/arm-none-linux-gnueabi-g++ -Os -pipe -Os -mabi=aapcs-linux -msoft-float -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 --sysroot /home/test/brtest-ext/staging/" FC="/home/test/arm-2009q3//bin/arm-none-linux-gnueabi-gfortran " RANLIB="/home/test/arm-2009q3//bin/arm-none-linux-gnueabi-ranlib" STRIP="/home/test/arm-2009q3//bin/arm-none-linux-gnueabi-strip" OBJCOPY="/home/test/arm-2009q3//bin/arm-none-linux-gnueabi-objcopy" AR_FOR_BUILD="/usr/bin/ar" AS_FOR_BUILD="/usr/bin/as" CC_FOR_BUILD="/usr/bin/gcc" GCC_FOR_BUILD="/usr/bin/gcc" CXX_FOR_BUILD="/usr/bin/g++" FC_FOR_BUILD="/usr/bin/ld" LD_FOR_BUILD="/usr/bin/ld" CFLAGS_FOR_BUILD="-I/home/test/brtest-ext/host/include -I/home/test/brtest-ext/host/usr/include" CXXFLAGS_FOR_BUILD="-I/home/test/brtest-ext/host/include -I/h
