C++ and dynamic linking

Shared objects may be created from C++ source as well as from C source. The foregoing discussion of creating and using C shared objects applies to C++ shared objects also, with two limitations:

• Using a shared object does not avoid the problem that any code using a class defined in the external interface to the library must be recompiled if the class definition changes. Executables and other libraries that depend on the class definition must be recompiled even if the change is in the private part of the class, since that will effect the offsets of the public and protected members and the offsets of any members of classes derived from that class.

• The programming interface to the dynamic linking mechanism is not available for any function with C++ linkage. If you intend for your library to be loaded with the dlopen(3C) interface, then the external interfaces must have C linkage, which precludes the use of C++ features. C++ linkage may still be used for symbols internal to the library.

An example would be this:

   so.h:
           #include <stdio.h>
   

           class A {
           public:
                   A(const char* s) { printf("ctor %s, object %x\n", s, this); }
           };
   

   so1.C:
           #include "so.h"
   

           A a("from so1.C");
   

   so2.C:
           #include "so.h"
   

           A a("from so2.C");
   

           int main() { }
   

   $ CC -G -KPIC -o libx.so so1.C
   $ CC so2.C libx.so
   $ a.out
   ctor from so1.C, object 8049840
   ctor from so2.C, object 8049840

Building a C++ shared object

The options to the CC command to create and locate shared objects are the same as the options to the cc command. The following command, for example, will create a shared object named libfoo.so from two C++ source files:

   $ CC -G -KPIC -o libfoo.so function1.C function2.C

To avoid dangling references, you should ensure that all templates referenced within a library are instantiated within the library.

Static constructors and destructors

Unlike an archive library, with a shared object the linker cannot determine what subset of functions and objects within a library are actually needed by the program, therefore, all the static constructors (destructors) in the shared object will be executed when the shared object is loaded (unloaded). The static constructors will be called in thereverse of the order the object files appear on the command line used to create the object. For example, given the following command line,

   $ CC -G function1.o function2.o function3.o

When multiple C++ shared objects are loaded, if shared object a depends on shared object b, the static constructors in shared object b will be executed first. There is no guarantee of any ordering of calls to static constructors between unrelated shared objects. When the program exits, the static destructors are called in the reverse order of the calls to the static constructors. If dlclose(3C) is used to explicitly close a shared object, static destructors may be executed out-of-sequence with respect to other static destructors in shared objects that are still open. (The ISO C++ standard considers that dynamic libraries are outside the scope of the standard, which means that behavior such as this does not constitute a violation of the standard.)

Diagnostics from the dynamic linker

The dynamic linker does not demangle any names in the diagnostics it produces. (See

``C++ external function name encoding''.)

If a diagnostic appears somewhat cryptic:

   $ a.out
   dynamic linker: a.out: symbol not found: g__Fv
   Killed

   $ a.out 2>/var/tmp/a.out.err
   Killed
   $ c++filt </var/tmp/a.out.err
   dynamic linker: a.out: symbol not found: g(void)