Debian Bug report logs - #367115
Libtool sets rpath when cross-compiling for default location

version graph

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

Reported by: Bas Wijnen <shevek@fmf.nl>

Date: Sat, 13 May 2006 21:03:19 UTC

Severity: minor

Found in version libtool/1.5.22-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, Kurt Roeckx <kurt@roeckx.be>:
Bug#367115; Package libtool. Full text and rfc822 format available.

Acknowledgement sent to Bas Wijnen <shevek@fmf.nl>:
New Bug report received and forwarded. Copy sent to Kurt Roeckx <kurt@roeckx.be>. Full text and rfc822 format available.

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

From: Bas Wijnen <shevek@fmf.nl>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: Libtool sets rpath when cross-compiling for default location
Date: Sat, 13 May 2006 22:46:37 +0200
Package: libtool
Version: 1.5.22-4
Severity: minor

Hi Kurt, :-)

Debian libtool does not set rpath for libraries and binaries which are
going to be installed in the standard locations ($prefix/lib,
$prefix/bin).  It does set it when cross compiling, though, to
"/usr/$arch/{lib,bin}".

In practice this is not a problem, because that directory will not exist
on the target for which the compilation is performed (if it has a
compiler at all, the one for that architecture will not be a
cross-compiler).  However, it is still incorrect.

I've seen this in combination with automake, and the bug may be there.
If so, please reassign. :-)

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.16-1-686
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

Versions of packages libtool depends on:
ii  autotools-dev                20060223.1  Update infrastructure for config.{
ii  cpp                          4:4.0.3-3   The GNU C preprocessor (cpp)
ii  file                         4.17-1      Determines file type using "magic"
ii  gcc [c-compiler]             4:4.0.3-3   The GNU C compiler
ii  gcc-2.95 [c-compiler]        1:2.95.4-24 The GNU C compiler
ii  gcc-4.0 [c-compiler]         4.0.3-2     The GNU C compiler
ii  libc6-dev [libc-dev]         2.3.6-7     GNU C Library: Development Librari

Versions of packages libtool recommends:
ii  libltdl3-dev                  1.5.22-4   A system independent dlopen wrappe

-- no debconf information



Information forwarded to debian-bugs-dist@lists.debian.org, Kurt Roeckx <kurt@roeckx.be>:
Bug#367115; 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 367115@bugs.debian.org (full text, mbox):

From: Ralf Wildenhues <Ralf.Wildenhues@gmx.de>
To: Bas Wijnen <shevek@fmf.nl>, 367115@bugs.debian.org
Subject: Re: Bug#367115: Libtool sets rpath when cross-compiling for default location
Date: Sun, 14 May 2006 05:51:22 +0200
Hi Bas,

* Bas Wijnen wrote on Sat, May 13, 2006 at 10:46:37PM CEST:
> 
> Debian libtool does not set rpath for libraries and binaries which are
> going to be installed in the standard locations ($prefix/lib,
> $prefix/bin).  It does set it when cross compiling, though, to
> "/usr/$arch/{lib,bin}".

Are they going to be searched by the linker (for dependent packages) by
default?

> In practice this is not a problem, because that directory will not exist
> on the target for which the compilation is performed (if it has a
> compiler at all, the one for that architecture will not be a
> cross-compiler).  However, it is still incorrect.

Yep.

> I've seen this in combination with automake, and the bug may be there.
> If so, please reassign. :-)

No, that is a Libtool issue.  For the cross compile situation,
/usr/$arch/lib should be added to sys_lib_search_path_spec.  But that
won't solve all problems.  And be sure not to do it for the installed
/usr/bin/libtool script!  (You could maybe think about adding a
/usr/$arch/bin/libtool which has that, and is configured for the
respective cross compiler.)

Cheers,
Ralf



Blocking bugs of 484277 added: 367115 Request was from "Neil Williams" <neil@codehelp.co.uk> to control@bugs.debian.org. (Thu, 25 Jun 2009 22:42:16 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Kurt Roeckx <kurt@roeckx.be>:
Bug#367115; Package libtool. (Fri, 26 Jun 2009 13:51:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Neil Williams <codehelp@debian.org>:
Extra info received and forwarded to list. Copy sent to Kurt Roeckx <kurt@roeckx.be>. (Fri, 26 Jun 2009 13:51:03 GMT) Full text and rfc822 format available.

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

From: Neil Williams <codehelp@debian.org>
To: 367115@bugs.debian.org
Cc: 484277@bugs.debian.org
Subject: Problem appears to be sys_lib_dlsearch_path_spec
Date: Fri, 26 Jun 2009 14:45:24 +0100
[Message part 1 (text/plain, inline)]
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=367115#10

/usr/$arch/lib is already set in sys_lib_search_path_spec via the
cross-compiler and --print-search-dirs, however, rpath persists.

After a little investigation with the Emdebian Crush builds, I got this
summary of the problems:

http://wiki.debian.org/EmdebianAuditRpath

I've only tested changes in a few packages but one thing that is
promising is adding the /usr/$arch/lib path to
sys_lib_dlsearch_path_spec as well as the existing setting in
sys_lib_search_path_spec causes libtool (and therefore make) to omit
any call to rpath when relinking the binary at the build stage. Doing
this via the cross-compiler will allow more arbitrary rpaths to be
allowed for useful purposes in upstream development.

Are there likely side-effects from this change?

The difference is that sys_lib_search_path_spec has abspath support to
handle the long-winded way that arm-linux-gnueabi-gcc outputs the
search directories:

libraries:
=/usr/lib/gcc/arm-linux-gnueabi/4.3.3/:/usr/lib/gcc/arm-linux-gnueabi/4.3.3/../../../../arm-linux-gnueabi/lib/arm-linux-gnueabi/4.3.3/:/usr/lib/gcc/arm-linux-gnueabi/4.3.3/../../../../arm-linux-gnueabi/lib/

That last one resolves to the /usr/$arch/lib/

$ realpath /usr/lib/gcc/arm-linux-gnueabi/4.3.3/../../../../arm-linux-gnueabi/lib/
/usr/arm-linux-gnueabi/lib

For dlsearch to gain the same listing, it will also need abspath support.

The problems appear to show up in packages that build against libraries
other than plain libc6 - simple packages that have no other build-dependencies only show an rpath to /usr/lib in the build log which libtool then removes. I think we need the same behaviour for /usr/$arch/lib.

(Note, this does need to come from --print-search-dirs output of the cross-compiler as these paths are not fixed and may change in future.)

-- 


Neil Williams
=============
http://www.data-freedom.org/
http://www.linux.codehelp.co.uk/
http://e-mail.is-not-s.ms/

[Message part 2 (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Kurt Roeckx <kurt@roeckx.be>:
Bug#367115; Package libtool. (Sun, 28 Jun 2009 11:36:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Neil Williams <codehelp@debian.org>:
Extra info received and forwarded to list. Copy sent to Kurt Roeckx <kurt@roeckx.be>. (Sun, 28 Jun 2009 11:36:05 GMT) Full text and rfc822 format available.

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

From: Neil Williams <codehelp@debian.org>
To: 484277@bugs.debian.org
Cc: 367115@bugs.debian.org
Subject: Possible fix
Date: Sun, 28 Jun 2009 12:33:34 +0100
[Message part 1 (text/plain, inline)]
Autotools and dpkg-cross could provide a simple fix:

lt_cv_sys_lib_dlsearch_path_spec="/usr/$(DEB_HOST_GNU_TYPE)/lib /lib /usr/lib /usr/local/lib"

The default path (on amd64) is:
libtool:sys_lib_dlsearch_path_spec="/lib /usr/lib /usr/local/lib /lib/x86_64-linux-gnu /usr/lib/x86_64-linux-gnu
"

So it looks like libtool is reading BUILD when it should be reading
HOST.

Now we can either fix this in dpkg-cross by setting
lt_cv_sys_lib_dlsearch_path_spec in the /etc/dpkg-cross/config* files
and hopefully we can fix this in libtool too.

dpkg-cross gives us a direct fix for current builds (i.e. without
regenerating the autotools data of a particular package) and a fix in
libtool gives us a long term fix.

It looks like the libtool macros are listening to the wrong environment
variables - BUILD (which doesn't change when cross-compiling) compared
to HOST (which does change and this change should affect libtool
generation from ./configure).

This change to a CDBS package removes the RPATH from the cross-built
binary packages:

DEB_CONFIGURE_EXTRA_FLAGS=lt_cv_sys_lib_dlsearch_path_spec="/usr/$(DEB_HOST_GNU_TYPE)/lib /lib /usr/lib /usr/local/lib"

By using HOST, it does not change the value from what would be
automatically generated in a native build.

Whether the *order* of the variables matters, I don't know. More
testing required but I'm thinking of putting this into dpkg-cross to
support such tests.

-- 


Neil Williams
=============
http://www.data-freedom.org/
http://www.linux.codehelp.co.uk/
http://e-mail.is-not-s.ms/

[Message part 2 (application/pgp-signature, inline)]

Blocking bugs of 484277 removed: 367115 Request was from "Neil Williams" <neil@codehelp.co.uk> to control@bugs.debian.org. (Thu, 02 Jul 2009 10:36:18 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Kurt Roeckx <kurt@roeckx.be>:
Bug#367115; Package libtool. (Wed, 18 Apr 2012 12:33:18 GMT) Full text and rfc822 format available.

Acknowledgement sent to Wookey <wookey@wookware.org>:
Extra info received and forwarded to list. Copy sent to Kurt Roeckx <kurt@roeckx.be>. (Wed, 18 Apr 2012 12:33:23 GMT) Full text and rfc822 format available.

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

From: Wookey <wookey@wookware.org>
To: 367115@bugs.debian.org
Subject: re: Libtool sets rpath when cross-compiling for default location
Date: Wed, 18 Apr 2012 13:27:48 +0100
To a large degree this issue is made moot by multiarch. The rpath
location is now the same as the runtime location (at least if it gets
the architecture right). 

We still don't want those rpaths, but a) libtool is less likely to try
and put them in if it notices that built-time and runtime locations
match and b) they will now point to the right place.

I haven't yet noticed the override in dpkg-cross autoconf cache
actually breaking anything:
# override libtool until #367115 is fixed
hostarch=dpkg-architecture
-qDEB_HOST_GNU_TYPE
lt_cv_sys_lib_dlsearch_path_spec="/usr/$hostarch/lib /lib /usr/lib /usr/local/lib"

but it is wrong for multiarch and it would be good to get rid of it.

I'm not sure to what degree we think this is still useful for old-style builds. In general I'd just
like to fix upstream (libtool, or the package in question) and remove bodgery like this.

I'll try and find out if there are cases where it interferes with multiarch crossbuilds or is still
needed for dpkg-cross cross-builds. If anyone else already knows that info would be welcome. 

Wookey
-- 
Principal hats:  Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/




Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Mon Apr 21 02:45:58 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.