bug-libtool
[Top][All Lists]
Advanced

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

Re: AC_LIBTOOL_SYS_DYNAMIC_LINKER "gcc -print-search-dirs" problem


From: Ralf Wildenhues
Subject: Re: AC_LIBTOOL_SYS_DYNAMIC_LINKER "gcc -print-search-dirs" problem
Date: Wed, 13 Sep 2006 17:30:31 +0200
User-agent: Mutt/1.5.13 (2006-09-01)

* Peter O'Gorman wrote on Wed, Sep 13, 2006 at 05:20:28PM CEST:
> On Sep 14, 2006, at 12:12 AM, Ralf Wildenhues wrote:

> >Alright, feel free to give it a shot.  From the Autoconf macro we know
> >that
> >   -LANG:=* | -LIST:* | -LNO:*
> >
> >should be ignored, for pathscale and some other compilers I have
> >forgotten now.  Otherwise your awk script seems to work with PGI,
> >Intel, and PathScale.
> 
> I don't think we need to worry about that as the test is specific to  
> gcc. However I'll think about it more tomorrow when I hack at it,  
> bedtime here now :)

Oh yes you do.  All compilers I listed can cause
  with_gcc=yes

to be set.  Surely, you can blame them for not being exactly like GCC,
but in practice that won't save us from bug reports.

Also my gcc likes to output stuff like
  /usr/lib/gcc/x86_64-linux-gnu/4.0.3/32
  /usr/lib/gcc/x86_64-linux-gnu/4.0.3
  /usr/lib/gcc/x86_64-linux-gnu/4.0.3/32
  /usr/lib/gcc/x86_64-linux-gnu/4.0.3
  /usr/lib/gcc/x86_64-linux-gnu/4.0.3/../../../../lib32
  /usr/lib/gcc/x86_64-linux-gnu/4.0.3/../../..
  /lib/../lib32
  /usr/lib/../lib32

for -m32, and
  /usr/lib/gcc/x86_64-linux-gnu/4.0.3
  /usr/lib/gcc/x86_64-linux-gnu/4.0.3
  /usr/lib/gcc/x86_64-linux-gnu/4.0.3/../../../../lib64
  /usr/lib/gcc/x86_64-linux-gnu/4.0.3/../../..
  /lib/../lib64
  /usr/lib/../lib64

without a flag (i.e., -m64).  Looks kinda scary to not have /usr/lib and
/usr/lib32 and /usr/lib64 in this list.  I propose to put both the
unnormalized and normalized paths (`cd "$path" && pwd`) in the list.  On
my system, that will still not get you /usr/lib (to which lib64 is a
symlink), so there is still a problem (you certainly don't want to get
run paths due to a /usr/lib/libfoo.la).  :-/

Furthermore, your test needs a $CPPFLAGS (it's valid to put -m32 in
CPPFLAGS and LDFLAGS).

Cheers,
Ralf




reply via email to

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