On Saturday 10 of September 2011 13:35:17 Jeffrey Walton wrote: > 2011/9/10 Paweł Sikora <pluto@xxxxxxxx>: > > 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...
