Question

Here’s the situation, I’ve got a C++ codebase which is using a recent GCC (4.3.3), but I need to link against an older library which was built using GCC 3.2.3. There is no newer version of the library available, I can’t go without it, and it’s closed source so it can’t be rebuilt.

This seems to pose a problem since there are ABI incompatibilities between GCC 4.3.3 and 3.2.3, so I’m trying to see what my options are for resolving this.

A few additional details:

• I can rebuild everything in my codebase with -fabi-version=1 to get the correct ABI version, but I am dependent on some newer features from libstdc++ version 6.
• All the C++ library dependencies outside the codebase are open source, so I can rebuild them as needed, except for this one library.
• Many C library dependencies that cannot be rebuilt or would be difficult to rebuild.
• The old library seems to be dependent on some libstdc++ version 5 features

I have so far tried:

• Rebuild all C++ code and dependent libraries with -fabi-version=1 and link against libstdc++ version 6. This fails with a handful of undefined symbol errors for C++ standard library symbols.
• Same as above but additionally link in the shared library for libstdc++ 5, this resolves the linker issues but appears to result in mixing of the two versions at runtime inside the legacy library, and that causes a crash.

I read this page: http://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html which seems to indicate that it can be possible to mix C++ ABI versions in an application to satisfy varying dependencies between libraries. It doesn’t seem to work very well here, though, unless I am missing something.

Any ideas?

Answer 1

Ok, your workaround is to:

• write a “C” interface to the old C++ library, compile with 3.2.3 so it will work.
• Now you can use the C interface in the new compiler.

You can write some C++ “wrapper” code around the C library so you will use it as C++ but this code will be built in the new compiler.