...
}
Dynamic Path Lookup
If you specify an embedded path while building the filtered shared library using the +b linker option, the dynamic loader attempts to use this dynamic path when it searches for the implementation library to load. For example:
$ ld
$ ld
$ cc prog.c libfilt.sl
$ mv libimpl1.sl /path/to/implementation/libs $ ./prog
You can use TLS in the implementation libraries even though they are
Maintaining filtered shared libraries
To maintain your filtered shared libraries, you must rebuild them when you make the following changes:
•Add or remove symbols from the set of exported symbols from the implementation libraries
•Change symbol types, for example, when an uninitialized data symbol (BSS symbol) is changed to an initialized data symbol (or
•Change the TLS (Thread Local Storage) size of an implementation library Even though the
$ odump
Function Level Versioning
A new type qualifier with syntax '__attribute__((version_id("<some version id string>"))' is supported that can be used to facilitate shared libraries to have different versions of the same function based on platform (11.0, 11.11 etc.) or any other factor. Existing user applications using these shared libraries do not require recompilation when migrated to next version of the OS. Binaries will continue to run with the older version of the function which is part of the shared library.
Example usage:
extern int y __attribute__((version_id("11.22")));
Version Control with Shared Libraries
NOTE: Beginning with the
When to Use Shared Library Versioning
For the most part, updates to a shared library must be completely
110 Creating and Using Libraries