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ł.
