JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
Linker and Libraries Guide     Oracle Solaris 11 Information Library
search filter icon
search icon

Document Information

Preface

Part I Using the Link-Editor and Runtime Linker

1.  Introduction to the Oracle Solaris Link Editors

2.  Link-Editor

3.  Runtime Linker

4.  Shared Objects

5.  Interfaces and Versioning

6.  Establishing Dependencies with Dynamic String Tokens

Part II Quick Reference

7.  Link-Editor Quick Reference

8.  Versioning Quick Reference

Naming Conventions

Defining a Shared Object's Interface

Versioning a Shared Object

Versioning an Existing (Non-versioned) Shared Object

Updating a Versioned Shared Object

Adding New Symbols

Internal Implementation Changes

New Symbols and Internal Implementation Changes

Migrating Symbols to a Standard Interface

Part III Advanced Topics

9.  Direct Bindings

10.  Mapfiles

11.  Extensibility Mechanisms

Part IV ELF Application Binary Interface

12.  Object File Format

13.  Program Loading and Dynamic Linking

14.  Thread-Local Storage

Part V Appendices

A.  Linker and Libraries Updates and New Features

B.  System V Release 4 (Version 1) Mapfiles

Index

Naming Conventions

A shared object follows a naming convention that includes a major number file suffix. See Naming Conventions. Within this shared object, one or more version definitions can be created. Each version definition corresponds to one of the following categories.

The following version definition naming conventions help indicate which of these categories the definition represents.

The first three of these categories indicate interface definitions. These definitions consist of an association of the global symbol names that make up the interface, with a version definition name. See Creating a Version Definition. Interface changes within a shared object are often referred to as minor revisions. Therefore, version definitions of this type are suffixed with a minor version number, which is based on the file names major version number suffix.

The last category indicates a change having occurred within the object. This definition consists of a version definition acting as a label and has no symbol name associated with it. This definition is referred to as being a weak version definition. See Creating a Weak Version Definition. Implementation changes within a shared object are often referred to as micro revisions. Therefore, version definitions of this type are suffixed with a micro version number based on the previous minor number to which the internal changes have been applied.

Any industry standard interface should use a version definition name that reflects the standard. Any vendor interfaces should use a version definition name unique to that vendor. The company's stock symbol is often appropriate.

Private version definitions indicate symbols that have restricted or uncommitted use, and should have the word “private” clearly visible.

All version definitions result in the creation of associated version symbol names. The use of unique names and the minor/micro suffix convention reduces the chance of symbol collision within the object being built.

The following version definition examples show the possible use of these naming conventions.

SVABI.1

Defines the System V Application Binary Interface standards interface.

SUNW_1.1

Defines an Oracle Solaris OS public interface.

SUNWprivate_1.1

Defines an Oracle Solaris OS private interface.

SUNW_1.1.1

Defines an Oracle Solaris OS internal implementation change.