How to build an application that requires both libstdc++.so.5 and libstdc++.so.6?

Question

I want to preface this with the important notice that I am not a C/C++ programmer, and know very little about how linkage of libraries works in C.

Our code uses libstdc++.so.6 (gcc 3.4, i think). We have third-party precompiled (closed source) libraries that use libstdc++.so.5 (gcc 2.something or 3.2, i think). This is on linux. We have both a .a and .so version of the third party lib.

Is it possible to build our app with the 3rd party libs? How? Is it possible to build/run our app without having libstdc++.so.5 installed our our machines, how?

If I've forgotten some critical information, please let me know - I hardly know whats relevant with this stuff. I realize that a complete answer probably won't be possible; I'm really looking for direction and guidance. Static link this, dynamic that, rebuild that, prebuild so-and-so, switch to version x, or symlink the quizdoodle, etc.

Update:

We tried using dlopen with RTLD_LOCAL to isolate the 3rd party library from the rest of our app. This seems to have mostly worked, however, we are left with large memory leaks for unknown reasons. We suspect that, when we call dlopen, the third party library pulls in symbols like malloc from the already loaded .so.6, and things get muddled up.

For giggles, we tried putting the third-party library into LD_PRELOAD, then ran our app, and the memory leaks seems to completely disappear.

Answer 1

You may try to build a wrapper library around your 3rd party library: use the static version of that library + link it with the static standard library (-static-libgcc - make sure you pick up a proper version via -L). The important thing to do is to close this wrapper library properly, i.e only symbols from the original 3rd party library should be exported, everything else should be hidden. This way you wrapper library will expose all needed symbols for your application and encapsulate standard stuff inside. Note it is not guaranteed to work especially if some memory operations are shared between your code and 3rd party code (e.g. you allocate memory in your code and deallocate in 3rd party)... in such case the only option can be to keep this 3rd party lib in a different process space.

I don't think the dynamic option mentioned above would work because you will get exactly same problem - just later.

In general it is better not to mix binaries with different run-times in the same process space. It is almost always a recipe for disaster.

Answer 2

Ask your vendor for a newer version of the library that uses something not horribly out of date. Failing that, you could see if your new application still works with the older version of the library and if necessary port it back. Trying to have two different versions of the same library is asking for pain and I don't think you'll find an acceptable solution.