This is the mail archive of the
gcc-help@gcc.gnu.org
mailing list for the GCC project.
Re: Static libstdc++ and link problems
- From: Christoph Bugel <chris at tti-telecom dot com>
- To: gcc-help at gcc dot gnu dot org
- Cc: Frederic RISS <frederic dot riss at st dot com>
- Date: Fri, 20 Jun 2003 03:42:42 +0300
- Subject: Re: Static libstdc++ and link problems
> I'm running a Solaris 8 box with gcc 3.2.2 and using GNU binutils. What
> I want to do is quite simple : I've a lib written in C++ and which
> exposes a C API. I would like the lib to only depend on the libc and not
> on libstdc++ ; so I try to link my solib with the static libstdc++.a.
>
> First, is this a totally dumb idea ?
No.. I've tried it too. I'ts tempting to have access to the benefits of
C++, and creating a library that 'just works', with no special
requirements at runtime.
Unfortunatley, I suspect that it isn't *supposed* to work properly.
For one, libstdc++.a is normally composed of non relocatable object
files (no -fPIC at compile time), and you're not supposed to put those
into your shared library. maybe this can be cured by recompiling
libstdc++ with your own CXXFLAGS. but I this hints that it's not the
most common thing to do...
I think the reason for this is that if libstdc++ allowed itself to be
present in an executable multiple times, conflicts would occur. for
example, the global 'cout' variable.
For the record -- putting libstdc++.a into an executable worked for me.
The obvious g++ -static hw.cc didn't work. I needed to use
gcc hw.cc -Wl,-B,static -lstdc++
Maybe it's possible to use at least a subset of C++.
If you find a good solution I'm interested to know :)
Christoph