Linking troubles with gcc 4.5

lfrfly@icqmail.com lfrfly@icqmail.com
Wed May 26 21:23:00 GMT 2010


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@icqmail.com
To: aph@redhat.com
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@icqmail.com 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. 

  



More information about the Gcc-help mailing list