Defining Unrelated Interfaces
The previous examples show how new version definitions added
to an object inherit any existing version definitions. You
can also create version definitions that are unique and
independent. In the following example, two new files,
bar1.c
and
bar2.c
, are added to the object
libfoo.so.1
. These files
contribute two new symbols, bar1
and
bar2
, respectively.
$ cat bar1.c extern void foo1(); void bar1() { foo1(); } $ cat bar2.c extern void foo2(); void bar2() { foo2(); }
These two symbols are intended to define two new public
interfaces. Neither of these new interfaces are related to
each other. However, each interface expresses a dependency
on the original SUNW_1.2
interface.
The following mapfile
definition creates
the required association.
$ cat mapfile
$mapfile_version 2
SYMBOL_VERSION SUNW_1.1 { # Release X
global:
foo1;
local:
*;
};
SYMBOL_VERSION SUNW_1.2 { # Release X+1
global:
foo2;
} SUNW_1.1;
SYMBOL_VERSION SUNW_1.2.1 { } SUNW_1.2; # Release X+2
SYMBOL_VERSION SUNW_1.3a { # Release X+3
global:
bar1;
} SUNW_1.2;
SYMBOL_VERSION SUNW_1.3b { # Release X+3
global:
bar2;
} SUNW_1.2;
The version definitions created in
libfoo.so.1
when using this
mapfile
, and their related
dependencies, can be inspected using
pvs
(1).
$ cc -o libfoo.so.1 -M mapfile -G foo.o bar1.o bar2.o data.o $ pvs -dv libfoo.so.1 libfoo.so.1; SUNW_1.1; SUNW_1.2: {SUNW_1.1}; SUNW_1.2.1 [WEAK]: {SUNW_1.2}; SUNW_1.3a: {SUNW_1.2}; SUNW_1.3b: {SUNW_1.2};
Version definitions can be used to verify runtime binding requirements. Version definitions can also be used to control the binding of an object during the objects creation. The following sections explore these version definition usages in more detail.