The mechanism of recording an soname within a shared object is essential if the shared object is ever processed from an archive library.
An archive can be built from one or more shared objects and then used to generate a dynamic executable or shared object. Shared objects can be extracted from the archive to satisfy the requirements of the link-edit. Unlike the processing of relocatable objects, which are concatenated to the output file being created, any shared objects extracted from the archive are recorded as dependencies. See Archive Processing for more details on the criteria for archive extraction.
The name of an archive member is constructed by the link-editor and is a concatenation of the archive name and the object within the archive. For example.
$ cc -o libfoo.so.1 -G -K pic foo.c $ ar -r libfoo.a libfoo.so.1 $ cc -o main main.o libfoo.a $ elfdump -d main | grep NEEDED  NEEDED 0x123 libfoo.a(libfoo.so.1)
Because a file with this concatenated name is unlikely to exist at runtime, providing an soname within the shared object is the only means of generating a meaningful runtime file name for the dependency.
The runtime linker does not extract objects from archives. Therefore, in this example, the required shared object dependencies must be extracted from the archive and made available to the runtime environment.