How to write C .so library to subsitute existing C++ .so library?

Question

Hi, all

Let me explain the scenario. We have a legacy C++ compiled .so library. The functions in this library are declared with extern "c" {}, so the library can be used by both C and C++ program, plus, for some reason it was created with--static-libgcc option.

This old library is very old and hard to maintain. Now we haved managed to write a subsitution of it, but in C language. Let's say the old library is called libfoo.so(old), and new one is libfoo.so(new). For a given bar.o, it can be linked with either old or new libfoo.so to create a executable, say, bar.exe. But the bar.exe can only run with the same .so library it linked before, by the other words, these two libraries are not mutual exchangable.

EDIT#1: I made a symbolic link named libfoo.so to point to libfoo.so(old) or libfoo.so(new). This symbolic link libfoo.so is in LD_LIBRARY_PATH at runtime.

EDIT#2: When I linked bar.o with old libfoo.so and generated bar.exe, if I run this bar.exe with new libfoo.so, it reported error of undefined symbols. By nm these two libfoo.so, I can find out these symbols in old one, but not in new one. The symbols are something like _ZSt4cerr, which is a C++ lib mangled name(I though it was brought by --static-libgcc), and of course the new libfoo.so does not contains those kind of symbols.

EDIT#3: If I just compile and link the C code with g++ instead of gcc, does it make any sense?

How should I implement this?

EDIT#4: Today I managed to compile/link the new C programed libfoo with g++ (with static libgcc, static libstdc++), this can lead to all c++ symbols to be contained in libfoo.so. This can make everything run smoothly, but not what I really want.

Answer 1

give them same name and put into different directories. use LD_LIBRARY_PATH env. variable to set directory with desired library before any other directories.

Answer 2

If you build and link with the new one, can you get it to link with the old one? It sounds like you generated a binary compatible library, but only in one direction.

Answer 3

Edit#2 helps.

Basically your bar.exe is trying to do the C++ runtime initialization for that library.

You will have to, at a minimum, provide empty implementations of identically mangled names so that the bar.exe can dynamically search your .so and find/call them.

If you are less lucky, you might need to actually have those functions do something meaningful that the up-level code interprets as success.

Good Luck