libtool
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: multilib dirs and ld.so


From: Ralf Wildenhues
Subject: Re: multilib dirs and ld.so
Date: Thu, 6 Sep 2007 00:25:40 +0200
User-agent: Mutt/1.5.13 (2006-08-11)

Hi Peter,

* Peter O'Gorman wrote on Wed, Sep 05, 2007 at 08:02:59AM CEST:
> Proposed patches for branch-1-5 and HEAD.
> 
> Okay to apply?

Not quite, I'm afraid.  First, please put $CPPFLAGS before $LDFLAGS, for
consistency.

Then, this code is used in each tag -- Fortran compilers don't like
files named conftest.c, nor do they like their contents.  ;-)
(even if the output is not used for non-C tags, the compile still
happens; I guess ac_link helps.)


Here's a list of GNU/Linux systems, what it does on them, and what would
be missing:

Debian etch/x86 (has only /lib):
----------------
before the patch and after the patch ok:
/lib /usr/lib /usr/lib/atlas/sse2 /usr/lib/sse2 /usr/lib/libc5-compat 
/lib/libc5-compat /usr/i486-linuxlibc1/lib /lib/i486-linux-gnu 
/usr/lib/i486-linux-gnu /usr/lib/atlas

(the system compiler isn't multi-ABI)

Ubuntu Dapper/x86_64 (/lib64 is a symlink to /lib, /lib32 exists):
--------------------
before the patch:
/lib /usr/lib /usr/local/lib /usr/lib /opt/lib /usr/lib/atlas

after the patch:
/lib64 /usr/lib64 /usr/local/lib /usr/lib /opt/lib /usr/lib/atlas

same with CPPFLAGS=-m32 LDFLAGS=-m32, after the patch:
/lib /usr/lib /usr/local/lib /usr/lib /opt/lib /usr/lib/atlas

This is clearly wrong (though I think it was that way before as well).


Ubuntu Dapper/x86:
------------------
/lib and /lib64 exist, /lib32 does not.

after the patch:
/lib /usr/lib /usr/local/lib /usr/lib /opt/lib /usr/lib/atlas

with -m64 and --host=x86_64-unknown-linux-gnu:
/lib /usr/lib /usr/local/lib /usr/lib /opt/lib /usr/lib/atlas

Sigh.


Gentoo/parisc (has only /lib):
--------------

before and after the patch:
/lib /usr/lib /usr/local/lib /usr/lib/opengl/xorg-x11/lib 
/usr/hppa2.0-unknown-linux-gnu/lib /usr/lib/gcc/hppa2.0-unknown-linux-gnu/4.1.2 
/usr/lib/gcc/hppa2.0-unknown-linux-gnu/4.1.1 
/usr/lib/gcc-lib/hppa2.0-unknown-linux-gnu/3.3.6


SuSE/ppc64 (has separate /lib and /lib64, no /lib32):
----------
before and after the patch:
/lib /usr/lib /usr/X11R6/lib64/Xaw95 /usr/X11R6/lib64/Xaw3d /usr/X11R6/lib64 
/usr/X11R6/lib/Xaw95 /usr/X11R6/lib/Xaw3d /usr/X11R6/lib 
/usr/powerpc-suse-linux/lib /usr/ppc-suse-linux/lib64 /usr/ppc-suse-linux/lib 
/usr/local/lib /usr/openwin/lib /opt/kde/lib /opt/kde2/lib /opt/kde3/lib 
/opt/gnome/lib /opt/gnome2/lib /lib64 /lib /usr/lib64 /usr/lib /usr/local/lib64 
/usr/openwin/lib64 /opt/kde/lib64 /opt/kde2/lib64 /opt/kde3/lib64 
/opt/gnome/lib64 /opt/gnome2/lib64 /opt/lib [...]

The /usr/lib is certainly problematic, /usr/lib contains lots of .la
files.  Everything after the first two entries comes from
/etc/ld.so.conf.

with CPPFLAGS=-m32 LDFLAGS=-m32, after the patch:
/lib /usr/lib /usr/X11R6/lib64/Xaw95 /usr/X11R6/lib64/Xaw3d /usr/X11R6/lib64 
/usr/X11R6/lib/Xaw95 /usr/X11R6/lib/Xaw3d /usr/X11R6/lib 
/usr/powerpc-suse-linux/lib /usr/ppc-suse-linux/lib64 /usr/ppc-suse-linux/lib 
/usr/local/lib /usr/openwin/lib /opt/kde/lib /opt/kde2/lib /opt/kde3/lib 
/opt/gnome/lib /opt/gnome2/lib /lib64 /lib /usr/lib64 /usr/lib /usr/local/lib64 
/usr/openwin/lib64 /opt/kde/lib64 /opt/kde2/lib64 /opt/kde3/lib64 
/opt/gnome/lib64 /opt/gnome2/lib64 /opt/mx/lib32/ /opt/mx/lib64/ /opt/lib [...]


RHEL 3/x86_64 (/lib64 and /lib exist):
-------------
after the patch:
/lib64 /usr/lib64 /usr/kerberos/lib /usr/kerberos/lib64 /usr/X11R6/lib 
/usr/X11R6/lib64 /usr/lib64/qt-3.1/lib

with -m32:
/lib /usr/lib /usr/kerberos/lib /usr/kerberos/lib64 /usr/X11R6/lib 
/usr/X11R6/lib64 /usr/lib64/qt-3.1/lib

Further, the indiscriminate use of ldd, or absolute file names in the
test of course prevents decent cross-compile results.  (Not that this
is much of a regression, the problem existed before.)

Ideally, I would like, in a system that also uses symlinks, to see
both the symlink and the real dir present in the search path.

We should consider just making this whole setting overridable at
configure time.

Cheers,
Ralf

> 2007-09-05  Peter O'Gorman  <address@hidden>
> 
>       * libtool.m4 (AC_LIBTOOL_SYS_DYNAMIC_LINKER) [linux]: Try to set
>       the dynamic linker search path properly for multilib case.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]