Question

I came across a project recently that created it’s shared object libraries by linking gcc generated object files (using the CC gnu makefile macro) with g++.

Aside from (possibly) ensuring the source code is encapsulated inside #ifdef __cplusplus / extern "c" { / #endif constructs to avoid name mangling problems, is there any reason why this would be … better?

Answer 1

If they only link with g++ then adding preprocessor checks and extern "C" is useless, that only affects preprocessing and compilation, at the linking stage that’s already done.

They might have wanted to ensure that exceptions could propagate through their C library, but to do that they only need to link to libgcc not libstdc++.

Maybe they just wanted the shared library to depend on libstdc++, so that users of the library would also depend on libstdc++ and wouldn’t have to link to it explicitly, although that might not work as they expected.

So in short, no, I can’t think of any good reason if all the code is C code and not C++ code.

However just because something is compiled with gcc doesn’t mean it’s C code, you can use the gcc executable to compile C++ code and it will invoke the C++ front-end (cc1plus) instead of the C front-end (cc1). If the C++ code uses the standard library then you either need to link with -lstdc++ or use g++ to link (which automatically links with -lstdc++). So maybe the answer is that it’s C++ code, and the fact they compiled the objects with gcc not g++ made you think it was C code.