gcc 4.0.0 x86_64 static linking of libstdc++.a

gcc 4.0.0 x86_64 static linking of libstdc++.a

[Roland Lengfeldner]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="us-ascii", Size: 1815 bytes --]

Hello,

I'm facing the following problem: I want to create a shared library on Linux
(Red Hat Enterprise 3) / Opteron, with gcc 4.0.0 & binutils 2.16. When
compiling in 32-bit mode (with -m32) everything works, but in 64-bit mode
(with -m64) the following error message appears:

gcc -shared   {list of .o files}  -ldl -lm

/opt/dessup/gnu_2004/gcc400/opt3/lib/gcc/x86_64-unknown-linux-gnu/4.0.0/../../../../lib64/libstdc++.a
 -m64 -static-libgcc -fPIC 
-Wl,-soname -Wl,libAGENT.so.1 -o .libs/libAGENT.so.1.0.0

/opt/dessup/gnu_2004/gcc400/opt3/bin/ld:
/opt/dessup/gnu_2004/gcc400/opt3/lib/gcc/x86_64-unknown-linux-gnu/4.0.0/../../../../lib64/libstdc++.a(functexcept.o):
relocation R_X86_64_32 against `std::bad_typeid::~bad_typeid()' can not be
used when making a shared object; recompile with
-fPIC
/opt/dessup/gnu_2004/gcc400/opt3/lib/gcc/x86_64-unknown-linux-gnu/4.0.0/../../../../lib64/libstdc++.a:
could not read symbols: Bad value
collect2: ld returned 1 exit status

all object files were compiled with the following switches (c/c++): -O3 
-fno-exception -m64 -fPIC

What does the error message mean? Is gcc 4.0.0 (or at least libstdc++.a)
miscompiled, or is it a gcc configuration problem:

gcc -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: /home/gcc_compile/opt3/gcc-4.0.0/configure 
--prefix=/opt/dessup/gnu_2004/gcc400/opt3 --disable-nls --disable-werror 
--with-local-prefix=/opt/dessup/gnu_2004/tools/opt3 --with-gnu-as 
--with-as=/opt/dessup/gnu_2004/gcc400/opt3/bin/as --with-gnu-ld 
--with-ld=/opt/dessup/gnu_2004/gcc400/opt3/bin/ld 
--enable-languages=c,c++,objc,java
Thread model: posix
gcc version 4.0.0

thanks for your time,
Roland Lengfeldner

-- 
5 GB Mailbox, 50 FreeSMS http://www.gmx.net/de/go/promail
+++ GMX - die erste Adresse für Mail, Message, More +++

Re: gcc 4.0.0 x86_64 static linking of libstdc++.a

[Nix]

On 23 May 2005, Roland Lengfeldner suggested tentatively:
> I'm facing the following problem: I want to create a shared library on Linux
> (Red Hat Enterprise 3) / Opteron, with gcc 4.0.0 & binutils 2.16. When
> compiling in 32-bit mode (with -m32) everything works, but in 64-bit mode
> (with -m64) the following error message appears:
> 
> gcc -shared   {list of .o files}  -ldl -lm
> 
> /opt/dessup/gnu_2004/gcc400/opt3/lib/gcc/x86_64-unknown-linux-gnu/4.0.0/../../../../lib64/libstdc++.a
>  -m64 -static-libgcc -fPIC 
> -Wl,-soname -Wl,libAGENT.so.1 -o .libs/libAGENT.so.1.0.0

Linking non-PIC code (as is generally contained in static libraries)
into shared libraries is not portable and can't be guaranteed to work.
(The GNU C library's dynamic linker fixes it up in many cases, but it
*will* fail on other OSes, notably Solaris).

> /opt/dessup/gnu_2004/gcc400/opt3/bin/ld:
> /opt/dessup/gnu_2004/gcc400/opt3/lib/gcc/x86_64-unknown-linux-gnu/4.0.0/../../../../lib64/libstdc++.a(functexcept.o):
> relocation R_X86_64_32 against `std::bad_typeid::~bad_typeid()' can not be
> used when making a shared object; recompile with
> -fPIC

Well, that's pretty clear: recompile libstdc++.a with -fPIC (which means
rebootstrapping GCC with distinctly unusual CXXFLAGS) or take out that
explciit linkage to libstdc++.a.

(You should be using the c++ or g++ drivers for this, anyway.)

> What does the error message mean? Is gcc 4.0.0 (or at least libstdc++.a)
> miscompiled, or is it a gcc configuration problem:

Neither: you're doing something risky, inefficient and not a good idea :/

-- 
`Once again, I must remark on the far-reaching extent of my
 ladylike nature.' --- Rosie Taylor

Re: gcc 4.0.0 x86_64 static linking of libstdc++.a

[Roland Lengfeldner]

First, of all, thanks for your answer.
 
> Well, that's pretty clear: recompile libstdc++.a with -fPIC (which means
> rebootstrapping GCC with distinctly unusual CXXFLAGS) or take out that
> explciit linkage to libstdc++.a.
>
Ok, I'm just doing a new bootstrap, in order to generate a libstdc++.a with
-fPIC.
 
> (You should be using the c++ or g++ drivers for this, anyway.)
>
No option, because I need to generate a file which does NOT depend on a
particular libstdc++.so file installed in a given directory, therefore
static linking with gcc. 

-- 
Weitersagen: GMX DSL-Flatrates mit Tempo-Garantie!
Ab 4,99 Euro/Monat: http://www.gmx.net/de/go/dsl

Re: gcc 4.0.0 x86_64 static linking of libstdc++.a

[Nix]

On Tue, 24 May 2005, Roland Lengfeldner stated:
> First, of all, thanks for your answer.
>> Well, that's pretty clear: recompile libstdc++.a with -fPIC (which means
>> rebootstrapping GCC with distinctly unusual CXXFLAGS) or take out that
>> explciit linkage to libstdc++.a.
>
> Ok, I'm just doing a new bootstrap, in order to generate a libstdc++.a with
> -fPIC.

OK.

>> (You should be using the c++ or g++ drivers for this, anyway.)
>>
> No option, because I need to generate a file which does NOT depend on a
> particular libstdc++.so file installed in a given directory, therefore
> static linking with gcc. 

This will cause (possibly severe) problems if you link anything else in
the eventual process image against libstdc++, especially different
versions of it, or if at any point exceptions need to traverse
inter-shared-library boundaries (because of your forcing of a static
libgcc). The least I'd expect is exceptions missing catches that you'd
expect under language rules they'd be caught by.

-- 
`Once again, I must remark on the far-reaching extent of my
 ladylike nature.' --- Rosie Taylor