Re: libtool does not recognize lib64 -- Update to Olly Betts' patch
On Sun, Nov 14, 2010 at 06:20:32PM +0100, Ralf Wildenhues wrote:
Hello, and sorry for the looong delay,
* Toshio Kuratomi wrote on Thu, Oct 21, 2010 at 08:18:58PM CEST:
On Mon, Sep 20, 2010 at 2:17 PM, Toshio Kuratomi a.bad...@gmail.com wrote:
On Mon, Sep 20, 2010 at 10:25:06PM +0200, Ralf Wildenhues wrote:
Anything I need to do to get this looked at?
I'm looking at it. The patch has issues, the approach itself has issues
too, and is definitely not ready for the upcoming release.
Details when I have them sorted out.
No problem, thsanks for looking.
/me Awaits list of things to work on :-)
ping? I'm happy to take up where Ollie left off to improve the
approach but I need to know what the issues that need to be resolved
are :-) There were no mentioned issues (except first run speed) when
Olly first proposed his patch:
http://lists.gnu.org/archive/html/libtool-patches/2010-06/msg00146.html
I haven't tested it much, so it would be nice if somebody could try out a
few distros/versions. On one system here, there are dangling links in
/usr/lib, and it seems to take *very* (I mean *really*) long for
ldconfig to finish (maybe even hang?).
I was unable to replicate (by putting dangling symlinks in both /usr/lib and
/usr/lib64). Does /sbin/ldconfig -v -N -X appear to hang in that directory
for you? If ldconfig completes, do subsequent runs of the patched libtool
then hang? (as the disk cache is then hot).
The code mistreats cross-compilation, but the code we have now does that
in the same way, so no big difference.
nod
The patch uses \? in sed which is unportable to non-GNU sed, but can be
replaced by \{0,1\} portably (when the s delimiter is also changed from
comma to, say, |):
/sbin/ldconfig -N -X -v 2/dev/null | sed 's|^\(/.*\):\(
(.*)\)\{0,1\}$|\1|p;d'
(Ignore that Solaris sed won't cope, see above note about cross issues.)
Changed.
Are there any distros where ldconfig is not in /sbin,
Updated this portion to use the same strategy used in other places (for
instance, finish_cmds):
PATH=\$PATH:/sbin ldconfig[...]
or the output
format varies? Should we consider using the old code as fall-back,
at least when ldconfig dies or errors out for some reason?
Updated to do two things:
1) Check whether the ldconfig command returns a failure exit code
2) Check whether the ldconfig command returned nothing
If either of these is true, then run the old code as a fallback.
I had someone check on FreeBSD and ldconfig there does not take the same
options and must be run as root. So the fallback routine is necessary.
One big issue is that the patch will add the wrong bitness directories
to the search path also, which means that libtool will find libraries
wrongly, and if there are .la files there also easily cause link
failures and such. I'm not exactly sure how to fix this.
Is this an issue? If so the current libtool code adds /lib and /usr/lib
to sys_lib_dlsearch_path_spec for 64bit builds even when /lib and /usr/lib
only have 32 bit binaries. The current code also picks up a mix of
/usr/lib64 and /usr/lib directories from the configuration in
/etc/ld.so.conf on a multilib box. The dynamic linker is responsible for
sorting out what libraries within the /etc/ld.so.conf configured paths are
appropriate for the arch that the program was compiled for, if libtool is
going to use that information it seems like it would need to take on the
same responsibility.
I'm not sure if this list is exhaustive.
nod. Thanks for reviewing. New patch attached.
-Toshio
From 42bcbdf4ffb7fe16d98ff264e11fd0d1b5e8d013 Mon Sep 17 00:00:00 2001
From: Toshio Kuratomi tos...@fedoraproject.org
Date: Mon, 15 Nov 2010 08:42:50 -0800
Subject: [PATCH] Olly Bett's patch to use ldconfig so that multilib boxes
properly pick up /lib64 and /usr/lib64 as being in the default search path with
the following changes suggested by Ralf Wildenhues:
* Make sed invokation portable to non-GNU sed
* Don't hardcode /sbin/ldconfig
* Use old detection code as a fallback
Additionally: don't hardcode sed use $SED
---
libltdl/m4/libtool.m4 | 14 ++
1 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4
index d8b3a4d..4365b68 100644
--- a/libltdl/m4/libtool.m4
+++ b/libltdl/m4/libtool.m4
@@ -2612,10 +2612,16 @@ linux* | k*bsd*-gnu | kopensolaris*-gnu)
# before this can be enabled.
hardcode_into_libs=yes
- # Append ld.so.conf contents to the search path
- if test -f /etc/ld.so.conf; then
-lt_ld_extra=`awk '/^include / { system(sprintf(cd /etc; cat %s
2/dev/null, \[$]2)); skip = 1; } { if (!skip) print \[$]0; skip = 0; }'
/etc/ld.so.conf | $SED -e 's/#.*//;/^[ ]*hwcap[]/d;s/[:, ]/
/g;s/=[^=]*$//;s/=[^= ]* / /g;s///g;/^$/d' | tr '\n' ' '`
-sys_lib_dlsearch_path_spec=/lib /usr/lib $lt_ld_extra
+ # Try to extract search path from ldconfig
+
Re: libtool does not recognize lib64 -- Update to Olly Betts' patch
On Mon, Sep 20, 2010 at 2:17 PM, Toshio Kuratomi a.bad...@gmail.com wrote: On Mon, Sep 20, 2010 at 10:25:06PM +0200, Ralf Wildenhues wrote: * Toshio Kuratomi wrote on Mon, Sep 20, 2010 at 10:20:09PM CEST: On Sat, Sep 11, 2010 at 04:04:04PM -0400, Toshio Kuratomi wrote: Greetings. I package software for Fedora and frequently get hit with /usr/lib64 being added as an rpath in builds. I found what I think is the last thread on this subject here: http://lists.gnu.org/archive/html/libtool-patches/2010-06/msg00141.html In the second message, Olly Betts links to a message from 2007 where he proposed a patch that would solve this by parsing the output of /sbin/ldconfig rather than trying to parse /etc/ld.so.conf. The thread ended with a positive view of the patch and a request to update the patch for current libtool. This last step doesn't appear to have happened. Since I care about this issue, I've gone ahead and ported the patch to current git master. I'm attaching it here. Anything I need to do to get this looked at? I'm looking at it. The patch has issues, the approach itself has issues too, and is definitely not ready for the upcoming release. Details when I have them sorted out. No problem, thsanks for looking. /me Awaits list of things to work on :-) ping? I'm happy to take up where Ollie left off to improve the approach but I need to know what the issues that need to be resolved are :-) There were no mentioned issues (except first run speed) when Olly first proposed his patch: http://lists.gnu.org/archive/html/libtool-patches/2010-06/msg00146.html -Toshio
Re: libtool does not recognize lib64 -- Update to Olly Betts' patch
On Sat, Sep 11, 2010 at 04:04:04PM -0400, Toshio Kuratomi wrote: Greetings. I package software for Fedora and frequently get hit with /usr/lib64 being added as an rpath in builds. I found what I think is the last thread on this subject here: http://lists.gnu.org/archive/html/libtool-patches/2010-06/msg00141.html In the second message, Olly Betts links to a message from 2007 where he proposed a patch that would solve this by parsing the output of /sbin/ldconfig rather than trying to parse /etc/ld.so.conf. The thread ended with a positive view of the patch and a request to update the patch for current libtool. This last step doesn't appear to have happened. Since I care about this issue, I've gone ahead and ported the patch to current git master. I'm attaching it here. Anything I need to do to get this looked at? Thanks, -Toshio pgpbSNk4aRWEo.pgp Description: PGP signature
Re: libtool does not recognize lib64 -- Update to Olly Betts' patch
* Toshio Kuratomi wrote on Mon, Sep 20, 2010 at 10:20:09PM CEST: On Sat, Sep 11, 2010 at 04:04:04PM -0400, Toshio Kuratomi wrote: Greetings. I package software for Fedora and frequently get hit with /usr/lib64 being added as an rpath in builds. I found what I think is the last thread on this subject here: http://lists.gnu.org/archive/html/libtool-patches/2010-06/msg00141.html In the second message, Olly Betts links to a message from 2007 where he proposed a patch that would solve this by parsing the output of /sbin/ldconfig rather than trying to parse /etc/ld.so.conf. The thread ended with a positive view of the patch and a request to update the patch for current libtool. This last step doesn't appear to have happened. Since I care about this issue, I've gone ahead and ported the patch to current git master. I'm attaching it here. Anything I need to do to get this looked at? I'm looking at it. The patch has issues, the approach itself has issues too, and is definitely not ready for the upcoming release. Details when I have them sorted out. Thanks, Ralf
Re: libtool does not recognize lib64 -- Update to Olly Betts' patch
On Mon, Sep 20, 2010 at 10:25:06PM +0200, Ralf Wildenhues wrote: * Toshio Kuratomi wrote on Mon, Sep 20, 2010 at 10:20:09PM CEST: On Sat, Sep 11, 2010 at 04:04:04PM -0400, Toshio Kuratomi wrote: Greetings. I package software for Fedora and frequently get hit with /usr/lib64 being added as an rpath in builds. I found what I think is the last thread on this subject here: http://lists.gnu.org/archive/html/libtool-patches/2010-06/msg00141.html In the second message, Olly Betts links to a message from 2007 where he proposed a patch that would solve this by parsing the output of /sbin/ldconfig rather than trying to parse /etc/ld.so.conf. The thread ended with a positive view of the patch and a request to update the patch for current libtool. This last step doesn't appear to have happened. Since I care about this issue, I've gone ahead and ported the patch to current git master. I'm attaching it here. Anything I need to do to get this looked at? I'm looking at it. The patch has issues, the approach itself has issues too, and is definitely not ready for the upcoming release. Details when I have them sorted out. No problem, thsanks for looking. /me Awaits list of things to work on :-) -Toshio pgpkEjZo5lfik.pgp Description: PGP signature
