Node and Host Name Sizes on HP-UX: Using the Expanded Capabilities of HP-UX

27
The following subsections also refer to this example.
Source and Binary Names and the Version Attribute
Before proceeding with the description of FLV, note the following terms need. These are used when
referring to interfaces exported from or imported into a compilation module.
source name
The name of an interface as written in the program’s source code file.
binary name
The name of an interface as it appears in the symbol table of the program’s
(relocatable) object file, as used by the object linker to bind the external references of
one object to another.
The source and binary names are usually the same. If the source program references the
logevent() function, that name appears in the symbol table of its compiled object file as an
undefined external function reference. For the source program that defines the logevent() function,
that name appears in its object symbol table as an exported function.
With FLV, the binary name might be different from the source name because FLV adds a version
identifier to the binary name. The version is specified as an attribute:
void logevent(struct eventinfo *evp,
void *eventdata) __attribute__((version_id("rev2"))) ;
The names of this log facility interface would be:
source name: logevent()
binary name: logevent{rev2}()
where {rev2} is the version identifier. This version identifier is applied to the symbol table entry of
all object files that reference the function, as well as to that of the object file that defines the function.
The significance of this is described in the next subsection.
Linking with Version Identifiers
The linker interprets the version identifier merely as part of the symbol name. As such, it requires that
the whole name, including the version identifier, match between the reference and the definition
before it can bind the reference.
Figure C-1 illustrates that an object that references the original, one-parameter, version of
logevent()properly links to an object that defines the original version of that function. An object
that references the new, two-parameter, version links to an object that defines that version. The
converse is not true. It is not possible for log.o to satisfy the reference to logevent{rev2}()
made by clientB.o. If only those two objects are passed to the linker, it will fail because the linker
cannot resolve logevent{rev2}(). Similarly, if only clientA.o and log_rev2.o are passed
to the linker, it will fail to resolve logevent().
Note that if both log.o and log_rev2.o are combined into a single library object, that library can
satisfy the external reference of either clientA.o or clientB.o.