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
