Can't cross-compile with same libdir as the host one

[Loïc Minier]

        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