Debian Bug report logs - #297726
link_all_deplibs=no in libtool.m4 assumes non-crosscompiling link er

version graph

Package: libtool; Maintainer for libtool is Kurt Roeckx <kurt@roeckx.be>; Source for libtool is src:libtool.

Reported by: Klimek Manuel <m.klimek@el-me.de>

Date: Wed, 2 Mar 2005 15:48:03 UTC

Severity: normal

Found in version 1.5.6-4

Reply or subscribe to this bug.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, Scott James Remnant <scott@netsplit.com>:
Bug#297726; Package libtool. Full text and rfc822 format available.

Acknowledgement sent to Klimek Manuel <m.klimek@el-me.de>:
New Bug report received and forwarded. Copy sent to Scott James Remnant <scott@netsplit.com>. Full text and rfc822 format available.

Message #5 received at submit@bugs.debian.org (full text, mbox):

From: Klimek Manuel <m.klimek@el-me.de>
To: "'submit@bugs.debian.org'" <submit@bugs.debian.org>
Subject: link_all_deplibs=no in libtool.m4 assumes non-crosscompiling link er
Date: Wed, 2 Mar 2005 16:12:30 +0100
Package: libtool
Version: 1.5.6-4

The libtool.m4 file which comes in this release differs
from the upstream libtool.m4 for libtool-1.5.6.

Especially the diff
5009,5011d5004
<   linux*)
<     _LT_AC_TAGVAR(link_all_deplibs, $1)=no
<   ;;

Sets link_all_deplibs to no on linux targets. Now
the problem is, that gnu-ld doesn't use rpath on
cross-compilation targets. Thus the link process
fails with unresolved symbol messages
when cross-compiling if dependent libraries
must be linked in.

Example: Library liba.so provides some functions,
libb.so depends on liba.so (libb_la_LIBADD=/path/to/liba.la)
now executable1 depends on libb.so. If I use
a native linker, everything is ok (ld just uses rpath
to find liba.so), but with a cross-compiling linker
liba.so is not found.
Solution: Don't use link_all_deplibs=no, but leave
it as 'unknown'

-- 
Manuel Klimek
EL-ME AG
Phone: +49 8752 864 0
Email : m.klimek@el-me.de



Information forwarded to debian-bugs-dist@lists.debian.org, Kurt Roeckx <kurt@roeckx.be>:
Bug#297726; Package libtool. Full text and rfc822 format available.

Acknowledgement sent to Ralf Wildenhues <Ralf.Wildenhues@gmx.de>:
Extra info received and forwarded to list. Copy sent to Kurt Roeckx <kurt@roeckx.be>. Full text and rfc822 format available.

Message #10 received at 297726@bugs.debian.org (full text, mbox):

From: Ralf Wildenhues <Ralf.Wildenhues@gmx.de>
To: Klimek Manuel <m.klimek@el-me.de>
Cc: 297726@bugs.debian.org
Subject: Re: link_all_deplibs=no in libtool.m4 assumes non-crosscompiling link er
Date: Wed, 30 Nov 2005 23:51:21 +0100
Hi Manuel,

Huge latency, sorry.  :-/

* Klimek Manuel wrote on Wed, Mar 02, 2005 at 04:12:30PM CET:
> 
> The libtool.m4 file which comes in this release differs
> from the upstream libtool.m4 for libtool-1.5.6.
> 
> Especially the diff
> 5009,5011d5004
> <   linux*)
> <     _LT_AC_TAGVAR(link_all_deplibs, $1)=no
> <   ;;
> 
> Sets link_all_deplibs to no on linux targets. Now
> the problem is, that gnu-ld doesn't use rpath on
> cross-compilation targets. Thus the link process
> fails with unresolved symbol messages
> when cross-compiling if dependent libraries
> must be linked in.

Will all your installed libraries live in /usr/lib or similar, where the
runtime linker will eventually find it without an rpath entry?

If yes, and it still fails, please show exactly how it fails.  For
libraries which won't need -rpath after they've been installed the
link_all_deplibs=no scenario has some hope of being fixed, see #320698.

> Solution: Don't use link_all_deplibs=no, but leave
> it as 'unknown'

That is surely a decent workaround, but may not be so good if the built
libraries should end up in a Debian package.

Cheers,
Ralf



Information forwarded to debian-bugs-dist@lists.debian.org, Kurt Roeckx <kurt@roeckx.be>:
Bug#297726; Package libtool. Full text and rfc822 format available.

Acknowledgement sent to "Klimek Manuel" <m.klimek@el-me.de>:
Extra info received and forwarded to list. Copy sent to Kurt Roeckx <kurt@roeckx.be>. Full text and rfc822 format available.

Message #15 received at 297726@bugs.debian.org (full text, mbox):

From: "Klimek Manuel" <m.klimek@el-me.de>
To: "Ralf Wildenhues" <Ralf.Wildenhues@gmx.de>
Cc: <297726@bugs.debian.org>
Subject: AW: link_all_deplibs=no in libtool.m4 assumes non-crosscompiling link er
Date: Thu, 1 Dec 2005 09:51:42 +0100
[Message part 1 (text/plain, inline)]
Hi Ralf,

> * Klimek Manuel wrote on Wed, Mar 02, 2005 at 04:12:30PM CET:
> > 
> > The libtool.m4 file which comes in this release differs from the 
> > upstream libtool.m4 for libtool-1.5.6.
> > 
> > Especially the diff
> > 5009,5011d5004
> > <   linux*)
> > <     _LT_AC_TAGVAR(link_all_deplibs, $1)=no
> > <   ;;
> > 
> > Sets link_all_deplibs to no on linux targets. Now the 
> problem is, that 
> > gnu-ld doesn't use rpath on cross-compilation targets. Thus 
> the link 
> > process fails with unresolved symbol messages when 
> cross-compiling if 
> > dependent libraries must be linked in.
> 
> Will all your installed libraries live in /usr/lib or 
> similar, where the runtime linker will eventually find it 
> without an rpath entry?

yes, they will, but runtime linkage is (for me) not the problem.

Here's an example project that shows what exactly fails:
(you'll need autoconf, automake, libtool and stuff to build)
Tested on debian sid, but should work on sarge ...

> tar xvzf miniproject.tar.gz
> cd miniproject
> make -f Makefile.autoconf

Native compilation:
-------------------
> mkdir native
> cd native
> ../configure --prefix=`pwd`/install
> make install > native.output
> cd ../

Cross compilation:
------------------
> /home/klimek/crosschain/bin/arm-linux-gcc -v
Reading specs from
/home/klimek/stuff/toolchains/mppl-terminal-voeb/toolchain/lib/gcc/arm-l
inux-uclibc/3.4.3/specs
Configured with:
/home/klimek/stuff/toolchains/mppl-terminal-voeb/build/toolchain/buildro
ot/toolchain_build_arm/gcc-3.4.3/configure
--prefix=/home/klimek/stuff/toolchains/mppl-terminal-voeb/toolchain
--build=i386-pc-linux-gnu --host=i386-pc-linux-gnu
--target=arm-linux-uclibc --enable-languages=c,c++ --enable-shared
--disable-__cxa_atexit --enable-target-optspace --with-gnu-ld
--disable-nls --enable-sjlj-exceptions
Thread model: posix
gcc version 3.4.3

> /home/klimek/crosschain/arm-linux-uclibc/bin/ld --version
GNU ld version 2.15.91.0.2 20040727
Copyright 2002 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms
of
the GNU General Public License.  This program has absolutely no
warranty.

> mkdir cross
> cd cross
> ../configure --prefix=`pwd`/install --host=arm-linux
CC=/home/klimek/crosschain/bin/arm-linux-gcc
> make install > cross.output

libtool: install: warning: relinking `libb.la'
/home/klimek/stuff/toolchains/mppl-terminal-voeb/toolchain/lib/gcc/arm-l
inux-uclibc/3.4.3/../../../../arm-linux-uclibc/bin/ld: warning:
liba.so.0, needed by ../libb/.libs/libb.so, not found (try using -rpath
or -rpath-link)
../libb/.libs/libb.so: undefined reference to `a'
collect2: ld returned 1 exit status
make[1]: *** [exec] Error 1
make: *** [install-recursive] Error 1

Explanation:
when gnu-ld links exec native, it will search the rpath in the library
to
resolve symbols recursively.
when gnu-ld links exec for cross compilation, it will not use rpath
(probably because it can't know the runtime linker that will be used).

Debian libtool has the diff:
> > Especially the diff
> > 5009,5011d5004
> > <   linux*)
> > <     _LT_AC_TAGVAR(link_all_deplibs, $1)=no
> > <   ;;

This means for linux targets the link_all_deplibs flag will always
be "no". If this variable is set to "no", libtool will not change it.
So gnu-ld fails for cross-compilation as in the example above.

Now if debian packages are cross-built, as far as I understood the
problem all upstream Makefile.am's have to be patched to include
all dependencies, which would be the same as not applying the mentioned
patch. Otherwise packages can not be cross-compiled.

Solutions I see:
a) patch gnu-ld to find out if rpath can be used to resolve dependant
symbols
b) set link_all_deplibs to "yes" for cross-compilation

Cheers,
Manuel





[miniproject.tar.gz (application/x-gzip, attachment)]

Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Sat Apr 19 18:52:52 2014; Machine Name: beach.debian.org

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.