libstdc++ compatibility frustrations under linux x86

Assume you have a static library LIB written in C++ that exports a C
interface like LIB_init(), LIB_action() and LIB_free(). Internally this LIB
is in C++ but from outsiders it must from C.
LIB is depending on STL and therefore depends on libstdc++. We cannot have
dynamic linking with libstdc++ since it causes compatibility problems if LIB
is used with a different compiler version for linking. libstdc++ only
guarranties binary compatibility between minor versions. To overcome this we
do static re-linking of the symbols into our library.

This relinking is done like:
ld -r $TMP/to_be_fixed.$O `$CXX --print-file-name=libstdc++.a`
`$CXX --print-file-name=libgcc_eh.a` -o $filename;

This will merge the libstdc++ symbols into our library... which is good.
Afterwards we need to hide them and we wrote a simple tool that works
together with objcopy. objcopy does the job of hiding the symbols... but we
furthermore change the section names to avoid same names between our library
and other code.

So now we have a another user who is using LIB into his application APP
(also c++ application).
This APP is compiled with an older g++ compiler more specifically g++ 3.3.6.
However for now he wants that his users should be able to use his
application on older linux.

He is therefore sending his libstdc++.so.* and libgcc.so* to the
end-users...

Now hell breaks loose though... since the library LIB starts to act weird
and not as documented. This has caused a number of days of work only to
realise what the problem is.

So LIB is suppose to use it's own private copy of libstdc++ instead of the
public one... however I'm not sure about the legality of sending out
libstdc++ libraries to other machines.
I said for now that the user should try to link the application statically
so they won't have a shared copy.

I'm unsure about this whole scenario. There is very little and sparse
documentation on this on the internet... this doesn't help in actually
finding out which of these steps are legal and which should be avoided.

Can anyone shed some light on this complex issue?

Thanks.

-- Henrik


.

Relevant Pages

  • Re: libstdc++ compatibility frustrations under linux x86
    ... Internally this LIB is in C++ but from outsiders it must from C. ... dynamic linking with libstdc++ since it causes compatibility problems if LIB is used with a different compiler version for linking. ... however I'm not sure about the legality of sending out libstdc++ libraries to other machines. ...
    (comp.unix.programmer)
  • Re: Getting started on the HP49g+
    ... either the original HP extable lib ... extable2 lib from http://www.hpcalc.org/details.php?id=3940. ... ask again if you have any problem installing libraries. ... compile the string with ASM (listed in the development lib menu, ...
    (comp.sys.hp48)
  • Re: How to "import" an interface into a module w/o `include?
    ... libs but not one file per lib. ... do you mean that you have used 'vlog' to compile your source files ... into ModelSim libraries of those names? ... could possibly know it's an interface). ...
    (comp.lang.verilog)
  • Re: RosAsm is a broken pile of crap
    ... armed with a macro assembler that's ... Even turbo pascal supported libraries (in the form of .tpu ... > Either the Lib is open source and free reuse. ... To use it in RosAsm, you'd have to convert it all to assembly. ...
    (alt.lang.asm)
  • Re: How to "import" an interface into a module w/o `include?
    ... libs but not one file per lib. ... do you mean that you have used 'vlog' to compile your source files ... into ModelSim libraries of those names? ... could possibly know it's an interface). ...
    (comp.lang.verilog)