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

[Ralf Wildenhues]

* Loïc Minier wrote on Tue, Nov 02, 2010 at 12:12:28AM CET:
> On Mon, Nov 01, 2010, Ralf Wildenhues wrote:
> > >  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.
> > 
> > Can you work around it by using the Libtool 2.4 --with-sysroot feature?
> > Please report back if that doesn't help.
> 
>  I didn't manage to get it working with this feature; I hope I'm using
>  it properly
> 
>  Starting from tests/depdemo as the previous time, I tried:
> ./configure --build=x86_64-linux-gnu --host=arm-linux-gnueabi 
> --libdir=/usr/lib --with-sysroot=/usr/arm-linux-gnueabi
> make install DESTDIR=`pwd`/destdir

This looks right to me.

>  and it fails as follows:

> libtool: install: warning: relinking `libl2.la'
> libtool: install: (cd 
> /home/lool/scratch/libtool/latest/libtool-2.4/tests/depdemo/l2; /bin/bash 
> /home/lool/scratch/libtool/latest/libtool-2.4/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/latest/libtool-2.4/tests/depdemo/destdir)
> libtool: relink: arm-linux-gnueabi-gcc -shared  -fPIC -DPIC  .libs/l2.o   
> -L/home/lool/scratch/libtool/latest/libtool-2.4/tests/depdemo/destdir/usr/lib 
> -L/usr/lib -ll1  -O2   -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

Can you work around it by passing suitable -Wl,-rpath-link,/...
arguments in link flags?  Since libtool doesn't grok -rpath-link (yet),
you'll need to prepend -W[cl], to the flag.

One thing that strikes me as not-so-easy to decide is if and when an
eventual fixed libtool should add -rpath-link by itself.  It would often
make sense to, at relink time, add one -rpath-link $DESTDIR/$ldir
for the -rpath $ldir that libtool *receives*.  Question is whether that
is sufficient, and whether that may already break stuff in some cases.

>  In any case, passing special ./configure flags would not make this
>  particular project easy as these are encoded in many individual Debian
>  source packages, so it would make it hard to cross-compile them without
>  modification.

Of course.  Still better than no solution at all though.  ;-)

Thanks,
Ralf