Dynamic Object Versioning - specifying a version binding

Rod Evans — Friday October 13, 2006

After reading a previous posting on versioning, a developer asked how they could specify what version to bind to when they built their application. For example, from the version definitions within libelf.so.1:

    % 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 defined by SUNW_1.4. Note, version SUNW_1.4 inherits previous versions.

The Linker and Libraries Guide covers this topic in the section Specifying a Version Binding. In a nutshell, you can specify a version control mapfile directive:

    % 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 from libelf to those provided by version SUNW_1.4.

Note, if you build against libelf.so.1 and discover a dependency on SUNW_1.5, then you are referencing interfaces from the 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 SUNW_1.5 interfaces.

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 N-1. 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.

Published Elsewhere

[23] Changing Paths with crle

Blog Index (rie)

[25] Displacement Relocation Warnings