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

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

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

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