custom libgcc, libstdc++ namespaces and .so names

custom libgcc, libstdc++ namespaces and .so names

[Paweł Sikora]

Hi,

we're developing a large c++ application which is compiled with 4.6 and deployed
to client's enterprise systems with various and ancient gcc runtime libs.

basically there's no problem with running such application on an old system
(we can provide fresh gcc runtime + use rpath $origin) but there's a major problem
when application's plugins (with c-style interface and internal c++ implementation)
are dlopen by 3-rd party software.

during dlopen the system loader injects (due to weak binding) old libgcc/libstdc++
symbols from 3-rd party software (e.g. eda simulator) into the plugin.
this usually ends with undefined references to new gcc symbols, mixed symbols
or weird crashes in random places.

to avoid such interoperablity problems we currently linking static libgcc/libstdc++
versions (./configured --with-pic) into shared application plugins. moreover we use
a linker .lds script to hide implementation details and export only c-style interface.
such software isolation generally works but has a limitation - it complicates
the build system horribly.

when core application uses e.g. libEngine.so (which throws std:: based exceptions
and it's linked with shared gcc runtime) the plugin for 3-rd party software can't
reuse libEngine.so directly due to applied isolation (e.g. dynamic_cast and exception
catching engine don't work without properly binded weak symbols). so we must
link plugin directly with Engine's .o(bjects) to close everyting in one isolated
plugin.

it would be nice to have a possiblity to pass some vendor specific string
to ./configure and decorate *.ver namespaces, std:: namespace and runtime sonames.

or maybe there's a hacky way with manual makefile and _GLIBCXX_* macros modifications?

thanks in advance for any hints!

BR,
Paweł.

Re: custom libgcc, libstdc++ namespaces and .so names

[Jeffrey Walton]

2011/9/10 Paweł Sikora <pluto@agmk.net>:
> Hi,
>
> we're developing a large c++ application which is compiled with 4.6 and deployed
> to client's enterprise systems with various and ancient gcc runtime libs.
>
> basically there's no problem with running such application on an old system
> (we can provide fresh gcc runtime + use rpath $origin) but there's a major problem
> when application's plugins (with c-style interface and internal c++ implementation)
> are dlopen by 3-rd party software.
>
> during dlopen the system loader injects (due to weak binding) old libgcc/libstdc++
> symbols from 3-rd party software (e.g. eda simulator) into the plugin.
> this usually ends with undefined references to new gcc symbols, mixed symbols
> or weird crashes in random places.
>
> to avoid such interoperablity problems we currently linking static libgcc/libstdc++
> versions (./configured --with-pic) into shared application plugins. moreover we use
> a linker .lds script to hide implementation details and export only c-style interface.
> such software isolation generally works but has a limitation - it complicates
> the build system horribly.
LDFLAGS += -Wl,-z,nodlopen

If they can't play nice in the same sandbox, don't play with them.

Jeff

Re: custom libgcc, libstdc++ namespaces and .so names

[Paweł Sikora]

On Saturday 10 of September 2011 13:35:17 Jeffrey Walton wrote:
> 2011/9/10 Paweł Sikora <pluto@agmk.net>:
> > Hi,
> >
> > we're developing a large c++ application which is compiled with 4.6 and deployed
> > to client's enterprise systems with various and ancient gcc runtime libs.
> >
> > basically there's no problem with running such application on an old system
> > (we can provide fresh gcc runtime + use rpath $origin) but there's a major problem
> > when application's plugins (with c-style interface and internal c++ implementation)
> > are dlopen by 3-rd party software.
> >
> > during dlopen the system loader injects (due to weak binding) old libgcc/libstdc++
> > symbols from 3-rd party software (e.g. eda simulator) into the plugin.
> > this usually ends with undefined references to new gcc symbols, mixed symbols
> > or weird crashes in random places.
> >
> > to avoid such interoperablity problems we currently linking static libgcc/libstdc++
> > versions (./configured --with-pic) into shared application plugins. moreover we use
> > a linker .lds script to hide implementation details and export only c-style interface.
> > such software isolation generally works but has a limitation - it complicates
> > the build system horribly.
> LDFLAGS += -Wl,-z,nodlopen
> 
> If they can't play nice in the same sandbox, don't play with them.
> 
> Jeff

such simple solution == -ENOINCOME ;)  but i'm playing now with libstgdc++.so.7
with fully versioned std:: namespace and so far it works fine with 3-rd party
"enterprise" enviroment...