Oracle® Solaris 11.2 Linkers and Libraries Guide

Exit Print View

Updated: July 2014

Coordination of Versioned Filenames

A link-edit commonly references shared object dependencies using the link-editors –l option. This option uses the link-editor's library search mechanism to locate shared objects that are prefixed with lib and suffixed with .so.

However, at runtime, any shared object dependencies should exist as a versioned file name. Instead of maintaining two distinct shared objects that follow two naming conventions, create file system links between the two file names.

For example, the shared object can be made available to the compilation environment by using a symbolic link. The compilation file name is a symbolic link to the runtime file name.

$ cc -o -G -K pic foo.c
$ ln -s
$ ls -l libfoo*
lrwxrwxrwx  1 usr grp          11 1991 ->
-rwxrwxr-x  1 usr grp        3136 1991

Either a symbolic link or hard link can be used. However, as a documentation and diagnostic aid, symbolic links are more useful.

The shared object has been generated for the runtime environment. The symbolic link, has also enabled this file's use in a compilation environment.

$ cc -o prog main.o -L. -lfoo

The link-editor processes the relocatable object main.o with the interface described by the shared object, which is found by following the symbolic link

Over a series of software releases, new versions of can be distributed with changed interfaces. The compilation environment can be constructed to use the interface that is applicable by changing the symbolic link.

$ ls -l libfoo*
lrwxrwxrwx  1 usr grp          11 1993 ->
-rwxrwxr-x  1 usr grp        3136 1991
-rwxrwxr-x  1 usr grp        3237 1992
-rwxrwxr-x  1 usr grp        3554 1993

In this example, three major versions of the shared object are available. Two versions, and, provide the dependencies for existing applications. offers the latest major release for creating and running new applications.

The use of this symbolic link mechanism solely is insufficient to coordinate the compilation shared object with a runtime versioned file name. As the example presently stands, the link-editor records in the dynamic executable prog the file name of the shared object the link-editor processes. In this case, that file name seen by the link-editor is the compilation environment file.

$ elfdump -d prog | grep libfoo
     [0]  NEEDED       0x1b7 

When the application prog is executed, the runtime linker searches for the dependency prog binds to the file to which this symbolic link is pointing.

To ensure the correct runtime name is recorded as a dependency, the shared object should be built with an soname definition. This definition identifies the shared object's runtime name. This name is used as the dependency name by any object that links against the shared object. This definition can be provided using the –h option during the creation of the shared object.

$ cc -o -G -K pic -h foo.c
$ ln -s
$ cc -o prog main.o -L. -lfoo
$ elfdump -d prog | grep libfoog
     [0]  NEEDED       0x1b7 

This symbolic link and the soname mechanism establish a robust coordination between the shared-object naming conventions of the compilation and runtime environment. The interface processed during the link-edit is accurately recorded in the output file generated. This recording ensures that the intended interface are furnished at runtime.