Re: AC_LIBTOOL_SYS_DYNAMIC_LINKER gcc -print-search-dirs problem

2006-10-19 Thread Peter O'Gorman 


On Sep 21, 2006, at 5:43 AM, Kate Minola wrote:

To followup on my previous post on this subject, I propose that in  
libtool.m4

in the macro AC_LIBTOOL_SYS_DYNAMIC_LINKER the line



Hi Kate,
I just applied a patch that I believe fixes your issue.
http://lists.gnu.org/archive/html/libtool-patches/2006-10/ 
msg8.html


If you wait ~24 hours, you can download the daily snapshot http:// 
www.gnu.org/software/libtool to verify it is fixed.


Sorry it took me so long to get around to it.

Peter


___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool

Re: AC_LIBTOOL_SYS_DYNAMIC_LINKER gcc -print-search-dirs problem

2006-09-20 Thread Kate Minola 

To followup on my previous post on this subject, I propose that in libtool.m4
in the macro AC_LIBTOOL_SYS_DYNAMIC_LINKER the line

 sys_lib_search_path_spec=`$CC -print-search-dirs | grep
^libraries: | $SED -e s
/^libraries:// -e s,=/,/,g`

be replaced with

--
 cat  conftest.$ac_ext  EOF
{
 n = split(\[$]0, c, :);
 for (i = 2; i = n; i++) {
   if (i == 2) {
 str = substr(c@:@i@:@,3,length(c@:@i@:@)-2);
   } else {
 str= c@:@i@:@;
   }
   m = split(str, d, /);

   if (d@:@m-1@:@ == ..) {
 m--;
 count = 1;
 while (d@:@m-1@:@ == ..) {
   m--;
   count += 1;
 }
 m -= count;
   }

   printf -L/;
   for (j = 2; j  m; j ++) {
 printf %s/, d@:@j@:@;
   }
   if (length(multi)  1) {
 if (d@:@m-1@:@ == lib) {
   printf %s, multi;
 }
   }
   printf  ;
 }
}
EOF
 sys_lib_search_path_spec=`$CC -print-search-dirs | tail -1 |  \
awk -v multi=\`gcc-print-multi-os-directory\` -f conftest.$ac_ext`
--

Comments?  Suggestions for improvement?

Kate Minola
University of Maryland, College Park


___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool

Re: AC_LIBTOOL_SYS_DYNAMIC_LINKER gcc -print-search-dirs problem

2006-09-14 Thread Peter O'Gorman 


On Sep 15, 2006, at 1:08 AM, Ralf Wildenhues wrote:

Hi Ralf,
Okay, I don't think my solution solves anything :/. My gcc compiler  
in /opt/gcc-4.0.1 only passes -L flags for /opt/gcc-4.0.1/lib/gcc/ 
powerpc-apple-darwin8.2.0/4.0.1 and /opt/gcc-4.0.1/lib, but -print- 
search-dirs also includes /usr/lib and /lib etc.




You may want to read this:
http://lists.gnu.org/archive/html/libtool-patches/2005-01/ 
msg00181.html

and then decide whether to ignore it or not.  If yes, then that should
be documented.

(I think the reverse downside was that gcc would not list search dirs
that don't exist at the time; but I haven't tested it either and can't
find a reference to this now.)


While looking into a patch for this, I notice that
sys_lib_search_path_spec is not a tagged var, so we run it for each
compiler for each tag, with the latest one it finds being the final
answer. Does not seem quite right to me.


Good catch.  Probably doing this for the C compiler only should be
enough.


Also we seem to use $AWK in libtool.m4 (and substituted into libtool)  
without setting it anywhere when $lt_cv_nm_interface = MS dumpbin






I also came up with the awk expression from hell :-)


Here is what should be a readable portable awk expression from hell,  
but I need to return to square 1 for an actual problem solution.


Peter

awk '
BEGIN {RS= ; FS=/; } /-L\// {
  foo=;
  for (i = NF; i  0; i--) {
if ($i !=   $i != .  $i != -L  $i != \n) {
  if ($i == ..) { count++ }
  else if (count == 0) {
if (foo == ) { foo=$i }
else { foo=$i / foo }
  }
  else { count-- }
}
else if ($i == -L) { foo=/ foo }
  }
  if (foo != ) { freq[foo]++ }
  if (freq[foo] == 1) { print foo }
}'




___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool

AC_LIBTOOL_SYS_DYNAMIC_LINKER gcc -print-search-dirs problem

2006-09-13 Thread Kate Minola 

On my x86_64-unknown-linux-gnu system, the m4 macro
AC_LIBTOOL_SYS_DYNAMIC_LINKER in libtool.m4
uses gcc -print-search-dirs to set  sys_lib_search_path_spec.

Unfortunately, -print-search-dirs lists -m32 library directories,
but gcc is in (default) -m64 mode on my system.  Consequently libtool
tries to link with the wrong library (32 bit when it should be using 64 bit).
The particular error message I get is

: /usr/local/gcc-4.1.1/x86_64-Linux/lib/../lib/libstdc++.so: could not
read symbols:
: File in wrong format

I can get the appropriate 64-bit directories to search by 'gcc -v -o
hello hello.c'
from a hello world program and then looking at the directories
following each -L.

If I then hack configure to explicitly set sys_lib_search_path_spec with these
directories, then
/usr/local/gcc-4.1.1/x86_64-Linux/lib/../lib64/libstdc++.so is used
and everything is fine.

Unfortunately, I do not have a small example to demonstrate the
problem.  I found
this while trying to compile givaro-3.2.1
(http://www-lmc.imag.fr/Logiciels/givaro/).

Any help or suggestions on what should be the appropriate change to
AC_LIBTOOL_SYS_DYNAMIC_LINKER to make it work in the multilib
environment
would be appreciated.

Kate Minola
University of Maryland, College Park


___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool

Re: AC_LIBTOOL_SYS_DYNAMIC_LINKER gcc -print-search-dirs problem

2006-09-13 Thread Ralf Wildenhues 
Hello Bob, Kate,

* Bob Friesenhahn wrote on Wed, Sep 13, 2006 at 04:34:52PM CEST:
 On Wed, 13 Sep 2006, Kate Minola wrote:
 
 On my x86_64-unknown-linux-gnu system, the m4 macro
 AC_LIBTOOL_SYS_DYNAMIC_LINKER in libtool.m4
 uses gcc -print-search-dirs to set  sys_lib_search_path_spec.

 I think that this is really a GCC bug.  I have the same problem under 
 Solaris.  Libtool should work around the GCC bug by detecting 64-bit 
 compilation and expanding the search path to look in the 64-bit 
 library directories first.

Would it be semantically correct for libtool to make use of any of
  gcc -print-multi-lib
  gcc -print-multi-directory
  gcc -print-multi-os-directory

?  If yes: which, and for which paths?  It seems of those, only the last
is understood by gcc 3.3; I have not tested earlier versions.

Cheers,
Ralf


___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool

Re: AC_LIBTOOL_SYS_DYNAMIC_LINKER gcc -print-search-dirs problem

2006-09-13 Thread Peter O'Gorman 


On Sep 13, 2006, at 11:34 PM, Bob Friesenhahn wrote:


On Wed, 13 Sep 2006, Kate Minola wrote:


On my x86_64-unknown-linux-gnu system, the m4 macro
AC_LIBTOOL_SYS_DYNAMIC_LINKER in libtool.m4
uses gcc -print-search-dirs to set  sys_lib_search_path_spec.

Unfortunately, -print-search-dirs lists -m32 library directories,
but gcc is in (default) -m64 mode on my system.  Consequently libtool
tries to link with the wrong library (32 bit when it should be  
using 64 bit).

The particular error message I get is


I think that this is really a GCC bug.  I have the same problem  
under Solaris.  Libtool should work around the GCC bug by detecting  
64-bit compilation and expanding the search path to look in the 64- 
bit library directories first.


Hi Bob,
As far as I'm aware there is not going to be a fix for this in gcc,  
so yes, we need to fix it.

Perhaps something like:

echo int main(){return 0;}  conftest.c
search_path=`$CC $CFLAGS -c conftest.c 21 | awk 'BEGIN {RS= } /^ 
[\]?-L/ {sub (-L,);print $0};'`

rm -f conftest.c conftest.o

Peter


___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool

Re: AC_LIBTOOL_SYS_DYNAMIC_LINKER gcc -print-search-dirs problem

2006-09-13 Thread Peter O'Gorman 


On Sep 13, 2006, at 11:41 PM, Peter O'Gorman wrote:



On Sep 13, 2006, at 11:34 PM, Bob Friesenhahn wrote:


On Wed, 13 Sep 2006, Kate Minola wrote:


On my x86_64-unknown-linux-gnu system, the m4 macro
AC_LIBTOOL_SYS_DYNAMIC_LINKER in libtool.m4
uses gcc -print-search-dirs to set  sys_lib_search_path_spec.

Unfortunately, -print-search-dirs lists -m32 library directories,
but gcc is in (default) -m64 mode on my system.  Consequently  
libtool
tries to link with the wrong library (32 bit when it should be  
using 64 bit).

The particular error message I get is


I think that this is really a GCC bug.  I have the same problem  
under Solaris.  Libtool should work around the GCC bug by  
detecting 64-bit compilation and expanding the search path to look  
in the 64-bit library directories first.


Hi Bob,
As far as I'm aware there is not going to be a fix for this in gcc,  
so yes, we need to fix it.

Perhaps something like:

echo int main(){return 0;}  conftest.c
search_path=`$CC $CFLAGS -c conftest.c 21 | awk 'BEGIN {RS= } /^ 
[\]?-L/ {sub (-L,);print $0};'`

rm -f conftest.c conftest.o


I really should try things before sending mail :)
gcc -v  -o conftest conftest.c 21 | awk 'BEGIN {RS= } /^[\]?-L/  
{sub (-L,); print $0};'


Peter



___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool

Re: AC_LIBTOOL_SYS_DYNAMIC_LINKER gcc -print-search-dirs problem

2006-09-13 Thread Ralf Wildenhues 
* Peter O'Gorman wrote on Wed, Sep 13, 2006 at 04:41:56PM CEST:

 As far as I'm aware there is not going to be a fix for this in gcc,  
 so yes, we need to fix it.
 Perhaps something like:
 
 echo int main(){return 0;}  conftest.c
 search_path=`$CC $CFLAGS -c conftest.c 21 | awk 'BEGIN {RS= } /^ 
 [\]?-L/ {sub (-L,);print $0};'`
 rm -f conftest.c conftest.o

Only as a last resort, if you ask me.  Other compilers love to
disguise as gcc, and Autoconf's AC_FC_LIBRARY_LDFLAGS is witness of
how helplessly maintenance-intensive an approach like the above is.

Cheers,
Ralf


___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool

Re: AC_LIBTOOL_SYS_DYNAMIC_LINKER gcc -print-search-dirs problem

2006-09-13 Thread Peter O'Gorman 


On Sep 13, 2006, at 11:49 PM, Ralf Wildenhues wrote:


Only as a last resort, if you ask me.  Other compilers love to
disguise as gcc, and Autoconf's AC_FC_LIBRARY_LDFLAGS is witness of
how helplessly maintenance-intensive an approach like the above is.


That's looking at all kinds of flags, in this case we're only  
interested in -L.


Peter


___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool

Re: AC_LIBTOOL_SYS_DYNAMIC_LINKER gcc -print-search-dirs problem

2006-09-13 Thread Ralf Wildenhues 
* Peter O'Gorman wrote on Wed, Sep 13, 2006 at 04:55:11PM CEST:
 On Sep 13, 2006, at 11:49 PM, Ralf Wildenhues wrote:
 
 Only as a last resort, if you ask me.  Other compilers love to
 disguise as gcc, and Autoconf's AC_FC_LIBRARY_LDFLAGS is witness of
 how helplessly maintenance-intensive an approach like the above is.
 
 That's looking at all kinds of flags, in this case we're only  
 interested in -L.

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.

Cheers,
Ralf


___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool

Re: AC_LIBTOOL_SYS_DYNAMIC_LINKER gcc -print-search-dirs problem

2006-09-13 Thread Peter O'Gorman 


On Sep 14, 2006, at 12:12 AM, Ralf Wildenhues wrote:


* Peter O'Gorman wrote on Wed, Sep 13, 2006 at 04:55:11PM CEST:

On Sep 13, 2006, at 11:49 PM, Ralf Wildenhues wrote:


Only as a last resort, if you ask me.  Other compilers love to
disguise as gcc, and Autoconf's AC_FC_LIBRARY_LDFLAGS is witness of
how helplessly maintenance-intensive an approach like the above is.


That's looking at all kinds of flags, in this case we're only
interested in -L.


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 :)


Peter


___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool

Re: AC_LIBTOOL_SYS_DYNAMIC_LINKER gcc -print-search-dirs problem

2006-09-13 Thread Peter Breitenlohner 

On Wed, 13 Sep 2006, Ralf Wildenhues wrote:


Also my gcc likes to output stuff like
..
 /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.


It's nice to know that gcc-4.0.3 has fixed one part of the problem. However,
not having /usr/lib, /lib, and /usr/local/lib is really bad. The above
output should be compared with the default (GNU) linker search path as,
e.g., in /usr/x86_64-linux-gnu/lib/ldsripts/elf_x86_64.x:

SEARCH_DIR(/usr/x86_64-linux-gnu/lib64);
SEARCH_DIR(/usr/local/lib64);
SEARCH_DIR(/lib64);
SEARCH_DIR(/usr/lib64);
SEARCH_DIR(/usr/x86_64-linux-gnu/lib);
SEARCH_DIR(/usr/local/lib);
SEARCH_DIR(/lib);
SEARCH_DIR(/usr/lib);

containing both .../lib64 and .../lib directories.

regards
Peter Breitenlohner [EMAIL PROTECTED]


___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool

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

2006-09-13 Thread Kate Minola 

Ralf, Peter,

Why not use the output of gcc -print-search-dirs
and, for every directory that ends with lib, append the
value returned by gcc -print-multi-os-directory?  Naturally
one will have to backup directories such as

/usr/lib/gcc/x86_64-linux-gnu/4.0.3/../../..

to realize that it ends with lib.  (Other than writing
a program, I do not see an easy way to do this last bit.)

Kate Minola
University of Maryland, College Park


___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool