C and C++ compilation system

Library maintenance

We have already seen how allocating buffers dynamically can ease the job of library maintenance. As a general rule, you want to be sure that updated versions of a shared object are compatible with its previous versions so that users will not have to recompile their applications. You should avoid changing the names of library symbols from one release to the next.

However, there may be instances in which you need to release a library version that is incompatible with its predecessor. On the one hand, you will want to maintain the older version for dynamically linked executables that depend on it. On the other hand, you will want newly created executables to be linked with the updated version. Moreover, you will probably want both versions to be stored in the same directory. In this example, you could give the new release a different name, rewrite your documentation, and so forth. A better alternative would be to plan for the contingency in the first instance by using the following sequence of commands when you create the original version of the shared object:

   $ cc -K PIC -G -h libfoo.1 -o libfoo.1 function1.c \
      function2.c function3.c
   $ ln libfoo.1 libfoo.so

In the first command -h stores the name given to it, libfoo.1, in the shared object itself. You then use the SCO OpenServer operating system command ln(C), to create a link between the name libfoo.1 and the name libfoo.so. libfoo.so is the name the link editor will look for when users of your library specify

   $ cc -Ldir file1.c file2.c file3.c -lfoo

However, the link editor will record in the user's executable the name you gave to -h, libfoo.1, rather than the name libfoo.so. That means that when you release a subsequent, incompatible version of the library, libfoo.2, executables that depend on libfoo.1 will continue to be linked with it at run time.

As shown earlier, the dynamic linker uses the shared object name that is stored in the executable to satisfy unresolved external references at run time.

You use the same sequence of commands when you create libfoo.2:

   $ cc -K PIC -G -h libfoo.2 -o libfoo.2 function1.c \
         function2.c function4.c
   $ ln libfoo.2 libfoo.so

When users specify

   $ cc -Ldir file1.c file2.c file3.c -lfoo

the name libfoo.2 will be stored in their executables, and their programs will be linked with the new library version at run time.