Removing the --enable-version-specific-runtime-libs configure option
appears to have solved my problem (so far, haven't actually run the
thing yet). Has that option been tested with 64-bit linux?
-----Original Message-----
From: lfrfly@xxxxxxxxxxx
To: aph@xxxxxxxxxx
Sent: Wed, May 26, 2010 3:07 pm
Subject: Re: Linking troubles with gcc 4.5
Reply below....
On 05/26/2010 05:50 PM, lfrfly@xxxxxxxxxxx wrote:
I recently built gcc 4.5 from source. That took a bit of doing, but
eventually I got to working. Since I don't have admin on this
machine, I
set the --prefix to /u1/public/gcc and make installed it there.
I am now able to compile with g++ 4.5. To help, I did
alias g++0x /u1/public/gcc/bin/g++ -std=c++0x
However, linking doesn't yet work. I got:
/usr/bin/ld: cannot find -lgcc_s
And when I changed the alias to include
-L/u1/public/gcc/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/
-L/u1/public/gcc/lib/gcc/x86_64-unknown-linux-gnu/lib/
then I got
/usr/bin/ld: skipping incompatible
/u1/public/gcc/lib/gcc/x86_64-unknown-linux-gnu/lib//libgcc_s.so
when
searching for -lgcc_s
/usr/bin/ld: cannot find -lgcc_s
Any ideas?
You haven't given us a huge amount of information: usually we'd
want the configure line and the command you use to do the test.
However, you can use "strace -etrace-file" to see where g++ is
looking
for libgcc_s.so. That'll give you a clue.
Andrew.
*************
Well, I've attached the strace output. I'm not sure if it'll be much
help; the only suspicious thing I see is that it's trying to access
/usr/lib at one point, and there could be files used by gcc 4.1 in
there.
Ahhh, "strace -f -etrace-file". And the output is for you to read.
:-)
As far as the configure line,
[***]$ g++0x -v
Using built-in specs.
COLLECT_GCC=/u1/public/gcc/bin/g++
COLLECT_LTO_WRAPPER=/u1/public/gcc/libexec/gcc/x86_64-unknown-linux-gnu/4
.5.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.5.0/configure --prefix=/u1/public/gcc
--enable-shared --enable-threads=posix --enable-__cxa_atexit
--enable-version-specific-runtime-libs
Thread model: posix
gcc version 4.5.0 (GCC)
Hmm, this isn't a Debian-derived distro, is it? They sometimes put
the libraries in the wrong place.
Andrew.
****************
Okay, the file that the -f option spat out is more useful. It appears
to be searching for libgcc_s.so in a bunch of places where it doesn't
exist. I've started a rebuild of gcc with the output redirected to a
file so that I can search it and see if that provides any clues. I also
removed the --enable-version-specific-runtime-libs configure option
just to see if that makes a difference.
And this is Redhat 5.5.
