Re: libtool does not recognize lib64 -- Update to Olly Betts' patch

[Toshio Kuratomi]

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 <address@hidden> 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

0001-Olly-Bett-s-patch-to-use-ldconfig-so-that-multilib-b.patch
Description: Text document

pgp6NM6k83mKm.pgp
Description: PGP signature