Redefining an Interface
One scenario is the consumption of an ISV specific interface into a public standard interface.
From the previous libfoo.so.1
example, assume that in
Release X+2
, the version
definition SUNW_1.1
is subdivided
into two standard releases,
STAND_A
and
STAND_B
. To preserve
compatibility, the SUNW_1.1
version definition must be maintained. In this
example, this version definition is expressed as
inheriting the two standard definitions.
$ pvs -dsv libfoo.so.1
libfoo.so.1:
_end;
_GLOBAL_OFFSET_TABLE_;
_DYNAMIC;
_edata;
_PROCEDURE_LINKAGE_TABLE_;
_etext;
SUNW_1.1: {STAND_A, STAND_B}:
SUNW_1.1;
SUNW_1.2: {SUNW_1.1}:
bar;
STAND_A:
foo1;
STAND_A;
STAND_B:
foo2;
STAND_B;
If the only requirement of application
prog
is the interface symbol
foo1
, the application will have
a single dependency on the version definition
STAND_A
. This precludes running
prog
on a system where
libfoo.so.1
is less than
Release X+2
. The version
definition STAND_A
did not exist
in previous releases, even though the interface
foo1
did.
The application prog
can be built
to align its requirement with previous releases by
creating a dependency on
SUNW_1.1
.
$ cat mapfile $mapfile_version 2 DEPEND_VERSIONS libfoo.so { ALLOW = SUNW_1.1; REQUIRE = SUNW_1.1; }; $ cat prog extern void foo1(); main() { foo1(); } $ cc -M mapfile -o prog prog.c -L. -R. -lfoo $ pvs -r prog libfoo.so.1 (SUNW_1.1);
This explicit dependency is sufficient to encapsulate the true dependency requirements. This dependency satisfies compatibility with older releases.