CODEWITHSUNDEEP
c++linux
Tim
Tim

Reputation: 99398

Why is extern "C" used with shared object library determined at runtime?

  1. I saw in a C++ program that dlfcn library is used for dynamically linking to a shared object library chosen by the user of the C++ program during runtime, and for calling functions in the chosen shared object library via dlsym() and other functions in dlfcn.

    • Assume the user chooses a shared object library called x.so during runtime. x.so was compiled from a cpp file with definitions of functions enclosed within extern "C". A comment in the cpp file says that the usage of extern "C" is important but without further explanation, and I wonder why?

    • Is it correct that there is only C++ code and no C code involved here? So is extern "C" not necessarily only used when mixing C and C++ code together?

    • Does whether dlfcn library is statically or dynamically linked to the C++ program matters to the questions above?

  2. Now compare to a simpler case, where the shared object library is known much earlier than runtime, and the author of the C++ program specifies it in the C++ program without using dlfcn before compiling it, and then dynamically links the shared object library and the C++ program during runtime. In this case, is `extern "C" still necessary in the cpp file which was compiled into the shared object library?

Thanks.

Upvotes: 0

Views: 1659

Answers (1)

davmac
davmac

Reputation: 20631

extern "C" changes the linkage, and affects name mangling. See What is name mangling, and how does it work?

Without it, exported names in the compiled object will normally be mangled. That means that they cannot be used from C. It also means that looking them up via dlsym() requires using the mangled name.

Is it correct that there is only C++ code and no C code involved here? So is extern "C" not necessarily used when mixing C and C++ code together?

It is not clear what you mean here. If you are compiling C++, then only C++ code is involved at this stage. If you are then linking in any way with a module written in C, then C is involved. If you need an external C library or program to link to your C++-defined functions, then they need to be declared extern "C".

Does whether dlfcn library is statically or dynamically linked to the C++ program matters to the questions above?

No (perhaps you should have explained why you think it might matter).

Now compare to a simpler case, where the shared object library is known much earlier than runtime, and the author of the C++ program specifies it in the C++ program without using dlfcn before compiling it, and then dynamically links the shared object library and the C++ program during runtime. In this case, is `extern "C" still necessary in the cpp file which was compiled into the shared object library?

It is necessary that the declared linkage of the symbols is consistent in the two C++ modules. Certainly, you could remove extern "C" if the modules are both C++. But if one module declares the symbol as extern "C" then the other must also.

Upvotes: 3

Related Questions