Dynamic Object Versioning - specifying a version binding
By user12613883 on Oct 13, 2006
After reading a previous posting on
a developer asked
how they could specify what version to bind to when they built their
application. For example, from the version definitions
% pvs -d /lib/libelf.so.1 libelf.so.1; SUNW_1.5; SUNW_1.4; .... SUNWprivate_1.1;
how could you restrict an application to only use the interfaces
SUNW_1.4. Note, version
inherits previous versions.
% cat mapfile libelf.so - SUNW_1.4;
Notice that the shared object name is the compilation environment name.
This is the name that gets resolved when you specify
-lelf. By adding this mapfile to your link-edit, the
link-editor will restrict the interfaces you are able to bind to
libelf to those provided by version
Note, if you build against
libelf.so.1 and discover a
SUNW_1.5, then you are referencing interfaces
SUNW_1.5 version. These will show up as undefined
errors if you build an application using the version control mapfile directive.
You'll have to recode your application to not use the
For example, this application is referencing gelf_getcap(3ELF).
% pvs -r prog libelf.so.1 (SUNW_1.5); .... % pvs -dos /lib/libelf.so.1 | fgrep SUNW_1.5 /lib/libelf.so.1 - SUNW_1.5: gelf_getcap; /lib/libelf.so.1 - SUNW_1.5: gelf_update_cap;
Note also, binding to specific versions is not a panacea for building
software on release
N and running on
Other factors can affect your build environment, such as headers.
It is always safest to build your software on the oldest platform on
which it is intended to run.
Of course, building on the latest release can provide a richer debugging environment in which to develop your software. I often try building things on the latest environment, and then fall back to the oldest environment for final testing and for creating final deliveries.
Technorati Tag: OpenSolaris
Technorati Tag: Solaris