[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Can't cross-compile with same libdir as the host one
From: |
Loïc Minier |
Subject: |
Can't cross-compile with same libdir as the host one |
Date: |
Sat, 23 Oct 2010 16:31:19 +0200 |
Hi there
(apologies for the long-list of Cc:)
As part of a project to cross-build Debian packages, I've been looking
into an issue which affects libtool packages. I can actually reproduce
the issue very easily with the libtool 2.2.6b release tarball (current
version in Debian/Ubuntu) and with the 2.4 tarball:
cd libtool/tests/depdemo
./configure --build=x86_64-linux-gnu --host=arm-linux-gnueabi --libdir=/usr/lib
make install DESTDIR=`pwd`/destdir
[...]
Making install in l2
make[1]: entrant dans le répertoire «
/home/lool/scratch/libtool/upstream/libtool-2.2.6b/tests/depdemo/l2 »
/bin/bash ../libtool --tag=CC --mode=compile arm-linux-gnueabi-gcc
-DPACKAGE_NAME=\"depdemo\" -DPACKAGE_TARNAME=\"depdemo\"
-DPACKAGE_VERSION=\"1.0\" -DPACKAGE_STRING=\"depdemo\ 1.0\"
-DPACKAGE_BUGREPORT=\"address@hidden" -DPACKAGE_URL=\"\" -DPACKAGE=\"depdemo\"
-DVERSION=\"1.0\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1
-DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1
-DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1
-DLT_OBJDIR=\".libs/\" -I. -I.. -g -O2 -c -o l2.lo l2.c
libtool: compile: arm-linux-gnueabi-gcc -DPACKAGE_NAME=\"depdemo\"
-DPACKAGE_TARNAME=\"depdemo\" -DPACKAGE_VERSION=\"1.0\"
"-DPACKAGE_STRING=\"depdemo 1.0\"" -DPACKAGE_BUGREPORT=\"address@hidden"
-DPACKAGE_URL=\"\" -DPACKAGE=\"depdemo\" -DVERSION=\"1.0\" -DSTDC_HEADERS=1
-DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1
-DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1
-DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -I. -I.. -g -O2 -c
l2.c -fPIC -DPIC -o .libs/l2.o
libtool: compile: arm-linux-gnueabi-gcc -DPACKAGE_NAME=\"depdemo\"
-DPACKAGE_TARNAME=\"depdemo\" -DPACKAGE_VERSION=\"1.0\"
"-DPACKAGE_STRING=\"depdemo 1.0\"" -DPACKAGE_BUGREPORT=\"address@hidden"
-DPACKAGE_URL=\"\" -DPACKAGE=\"depdemo\" -DVERSION=\"1.0\" -DSTDC_HEADERS=1
-DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1
-DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1
-DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -I. -I.. -g -O2 -c
l2.c -o l2.o >/dev/null 2>&1
/bin/bash ../libtool --tag=CC --mode=link arm-linux-gnueabi-gcc -g -O2
-no-undefined -o libl2.la -rpath /usr/lib l2.lo ../l1/libl1.la
libtool: link: arm-linux-gnueabi-gcc -shared .libs/l2.o -Wl,-rpath
-Wl,/home/lool/scratch/libtool/upstream/libtool-2.2.6b/tests/depdemo/l1/.libs
../l1/.libs/libl1.so -Wl,-soname -Wl,libl2.so.0 -o .libs/libl2.so.0.0.0
libtool: link: (cd ".libs" && rm -f "libl2.so.0" && ln -s "libl2.so.0.0.0"
"libl2.so.0")
libtool: link: (cd ".libs" && rm -f "libl2.so" && ln -s "libl2.so.0.0.0"
"libl2.so")
libtool: link: arm-linux-gnueabi-ar cru .libs/libl2.a l2.o
libtool: link: arm-linux-gnueabi-ranlib .libs/libl2.a
libtool: link: ( cd ".libs" && rm -f "libl2.la" && ln -s "../libl2.la"
"libl2.la" )
make[2]: entrant dans le répertoire «
/home/lool/scratch/libtool/upstream/libtool-2.2.6b/tests/depdemo/l2 »
test -z "/usr/lib" || /bin/mkdir -p
"/home/lool/scratch/libtool/upstream/libtool-2.2.6b/tests/depdemo/destdir/usr/lib"
/bin/bash ../libtool --mode=install /usr/bin/install -c libl2.la
'/home/lool/scratch/libtool/upstream/libtool-2.2.6b/tests/depdemo/destdir/usr/lib'
libtool: install: warning: relinking `libl2.la'
libtool: install: (cd
/home/lool/scratch/libtool/upstream/libtool-2.2.6b/tests/depdemo/l2; /bin/bash
/home/lool/scratch/libtool/upstream/libtool-2.2.6b/tests/depdemo/libtool --tag
CC --mode=relink arm-linux-gnueabi-gcc -g -O2 -no-undefined -o libl2.la -rpath
/usr/lib l2.lo ../l1/libl1.la -inst-prefix-dir
/home/lool/scratch/libtool/upstream/libtool-2.2.6b/tests/depdemo/destdir)
libtool: relink: arm-linux-gnueabi-gcc -shared .libs/l2.o
-L/home/lool/scratch/libtool/upstream/libtool-2.2.6b/tests/depdemo/destdir/usr/lib
-L/usr/lib -ll1 -Wl,-soname -Wl,libl2.so.0 -o .libs/libl2.so.0.0.0
/usr/lib/gcc/arm-linux-gnueabi/4.4.5/../../../../arm-linux-gnueabi/bin/ld:
skipping incompatible /usr/lib/libc.so when searching for -lc
/usr/lib/libc.a: could not read symbols: File format not recognized
Now, it would be possible to workaround this by configuring binutils to
support the host as a bfd target, and ld would just skip this x86-64
library, but I think it's a bad idea as it would probably break subtly
in x86 -> x86 cross-builds.
It is entirely possible that this is a toolchain bug, but I think
libtool has this design to use -rpath to specify the installation
directory, which might be why the linker looks in this directory.
Is this a libtool bug? I wonder whether libtool should pass
-rpath-link instead.
I did manage to workaround this by setting hardcode_automatic=yes in
libtool after ./configure (is there a way to set this directly for all
builds or on the configure cmdline?). With hardcode_automatic=yes, I
can install fine; this works both with libtool 2.4 and 2.2.6b.
If you'd like to reproduce this, I'm using the armel cross toolchain
from the development Ubuntu version ("natty"), but the same problem is
probably visible in Ubuntu 10.10 ("maverick"). This toolchain is
provided by the binutils-arm-linux-gnueabi and gcc-arm-linux-gnueabi
packages.
Thanks!
--
Loïc Minier
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Can't cross-compile with same libdir as the host one,
Loïc Minier <=