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  <[EMAIL PROTECTED]>
> 
>       * libtool.m4 (AC_LIBTOOL_SYS_DYNAMIC_LINKER) [linux]: Try to set
>       the dynamic linker search path properly for multilib case.


_______________________________________________
http://lists.gnu.org/mailman/listinfo/libtool

Reply via email to