I'm trying to do static linking of libstdc++ into a shared object but it 
seems libstdc++ has not been compiled with PIC option under this platform.
What I want is to have a shared object (*.so) which is independent of the 
libstdc++ version installed on the users computer. This works fine under 
Linux x86.

When trying to do the linking I get errors like:

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
/root/libstdc++.a: could not read symbols: Bad value
collect2: ld returned 1 exit status

Reading newsgroups and other mailing lists it seems I need to recompile 
libstdc++ to make it work. Is there an easy way to do this? My plan is to 
create a cross compiler anyway so maybe I can do it at the same time.

Maybe someone knows some good documents describing this? So far I tried 
atleast 2 Linux dists (debian and now suse) and it seems both have non-pic 
versions of libstdc++.a.

Thanks in advance.

-- John 

"John Smith" <js@x-formation.com> writes:

> I'm trying to do static linking of libstdc++ into a shared object but it 
> seems libstdc++ has not been compiled with PIC option under this platform.
> What I want is to have a shared object (*.so) which is independent of the 
> libstdc++ version installed on the users computer. This works fine under 
> Linux x86.

If the user links against your DSO *and* libstdc++.{so,a} installed
on his system, and if his version of libstdc++ differs from yours,
you'll have to do a lot more then simply link libstdc++.a into
your DSO.

If you don't, the user will likely crash (as I told you before):
http://groups.google.com/group/comp.unix.programmer/browse_frm/thread/740f5cb42ca43

> Reading newsgroups and other mailing lists it seems I need to recompile 
> libstdc++ to make it work. 

Correct.

> Is there an easy way to do this?

Sure: rebuild your version of g++ "normally", then:

  cd x86_64-*linux-gnu/libstdc++-v3; make clean; 
  make CXXFLAGS='-g -O2 -D_GNU_SOURCE -fPIC'

and you should be good to go.

> Maybe someone knows some good documents describing this? 

Does above count as a "document" ?

> So far I tried 
> atleast 2 Linux dists (debian and now suse) and it seems both have non-pic 
> versions of libstdc++.a.

Yes, libstdc++.a is normally built non-PIC ...

Cheers,
-- 
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.

> If the user links against your DSO *and* libstdc++.{so,a} installed
> on his system, and if his version of libstdc++ differs from yours,
> you'll have to do a lot more then simply link libstdc++.a into
> your DSO.
>
> If you don't, the user will likely crash (as I told you before):

I'm not sure what you're indicating but here is what I'm doing:

1. Compile *.c and *.cpp into *.o files with -fpic flag.
2. Link with -shared flag, a version-script (which tells the public symbols 
and that rest will be local) and of course the libstdc++.a file.

Since the version script only makes a few symbols public and rest local I 
don't see the problem:

myfile
{
global:
a;
b;
c;
....

local:
*;
};

If I did the objcopy step on the object files instead I would not have to 
link with stdc++.a because there would be no references to it. But from what 
I understand the result should be the same.

>> Is there an easy way to do this?
>
> Sure: rebuild your version of g++ "normally", then:
>
>  cd x86_64-*linux-gnu/libstdc++-v3; make clean;
>  make CXXFLAGS='-g -O2 -D_GNU_SOURCE -fPIC'
>
> and you should be good to go.
>

Thanks. I'll give this a try.

For some reason Apple stopped shipping libstdc++.a on Mac OS (starting with 
10.3.9 and up) and wants everyone only to use libstdc++.dylib. Naturally 
this causes some problems because it prevents me from doing this trick with 
objcopy in order to make object files which are independent of c++ 
dependencies. Maybe I could just compile my own libstdc++ and use it?
What alternatives do I have? When shipping binaries or dylibs it's not a big 
problem to rely on their libstdc++.dylib but for object files I could be 
stuck as with linux platform. They say that the binary interface shouldn't 
change but for some reason I don't believe in miracles so I better solve the 
problems myself.

Thanks in advance.

-- John