extern "C" - C++ Forum
On all C++ compilers, extern "C" {} turns off mangling so C++ can call C. You use it in the C++ files only, to call C functions that have no C++ versions, i.e., when necessary.
Newer C compilers can mangle names and call C++ functions, if you declare them with extern "C++" in the C files only.
cc -c compiles something.c into (usually) something.o, an unlinked object file. If you want to link to static library somelib.a or prepare it to run-time link to dynamic library somelib.so, a second pass of cc -o something, or an internal second pass if no -c, links (actually using ld) the .o and library stuff together to an exec() friendly executable object file. Static libraries are archves from ar of *.o files, and ld copies the relevant parts of them into the statically linked executable. Dynamic libraries can be made for static ones, perhaps internally linking modules that call each other, and of course geting a new suffix and magic. Dynamic executable files just have stubs to allow a call to ld() at run time to find .so libraries in the original or $LD_LIBRARY_PATH directories, mmap() them into the memory space of the process, and set pointers to the mapped parts. All running copies of 'something' use the same *.so file mapped into the same RAM pages, except for initialized modifiable variables, which are often just initialization constants and a spec for variable space, so non-variable parts can be mapped into read-only pages. Statically linked copies of something *might* all use separate RAM copies of the code, if exec() does not use mmap(), and they roll out on separate parts of swap. Dynamic is especially wise when many programs use the same calls, so they use the same RAM & cache, and not so much swap. For instance, most C programs use libc, so it is linked by default. In dynamic mode, all C programs use the same libc.so mapped in the same RAM pages. If your dynamically linked executable goes to machines with a too different libc.so, they fail. Static linking means that never happens. Dynamic linking is for real men!
You can ensure the right libraries are found with $LD_LIBRARY_PATH, just the same way you might control where 'cc' is found using $PATH.
BTW, set-uid and set-gid executables unset the $LD_LIBRARY_PATH so you need to compile them without moving the .so from run time, and often with a cc option like -R to burn in fixed library paths at compile time. This is why it is so hard to write a set-uid script -- interpreter cannot link. You have to write your own fixed path interpreter wrapper!