Red Hat Summit Red Hat SummitSupportConsoleDéveloppeursCommencer un essaiContact

Ce contenu n'est pas disponible dans la langue sélectionnée.

Chapter 17. Creating libraries with GCC

This chapter describes steps for creating libraries and explains the necessary concepts used by the Linux operating system for libraries.

17.1. Library Naming Conventions
Copier lien

A special file name convention is used for libraries: A library known as foo is expected to exist as the file libfoo.so or libfoo.a. This convention is automatically understood by the linking input options of gcc, but not by the output options:

  • When linking against the library, the library can be specified only by its name foo with the -l option as -lfoo: 

    $ gcc ... -lfoo ...
    Copy to Clipboard Toggle word wrap
  • When creating the library, the full file name libfoo.so or libfoo.a must be specified.

Additional Resources

17.2. The soname Mechanism
Copier lien

Dynamically loaded libraries (shared objects) use a mechanism called soname to manage multiple compatible versions of a library.

Prerequisites

Problem Introduction

A dynamically loaded library (shared object) exists as an independent executable file. This makes it possible to update the library without updating the applications that depend on it. However, the following problems arise with this concept:

  • The identification of the actual version of the library
  • The need for multiple versions of the same library present
  • The signalling of ABI compatibility of each of the multiple versions

The soname Mechanism

To resolve this, Linux uses a mechanism called soname.

A library foo version X.Y is ABI-compatible with other versions with the same value of X in the version number. Minor changes preserving compatibility increase the number Y. Major changes that break compatibility increase the number X.

The actual library foo version X.Y exists as the file libfoo.so.x.y. Inside the library file, a soname is recorded with the value libfoo.so.x to signal the compatibility.

When applications are built, the linker looks for the library by searching for the file libfoo.so. A symbolic link with this name must exist, pointing to the actual library file. The linker then reads the soname from the library file and records it into the application executable file. Finally, the linker creates the application so that it declares dependency on the library using the soname, not name or file name.

When the runtime dynamic linker links an application before running, it reads the soname from the executable file of the application. This soname is libfoo.so.x. A symbolic link with this name must exist, pointing to the actual library file. This allows loading the library, regardless of the Y component of the version, because the soname does not change.

Note

The Y component of the version number is not limited to just a single number. Additionally, some libraries encode the version in their name.

Reading soname from a File

To display the soname of a library file somelibrary: 

$ objdump -p somelibrary | grep SONAME
Copy to Clipboard Toggle word wrap

Replace somelibrary with the actual file name of the library you wish to examine.

17.3. Creating Dynamic Libraries with GCC
Copier lien

Dynamically linked libraries (shared objects) allow resource conservation through code reuse and increased security by easier updates of the library code. This section describes the steps to build and install a dynamic library from source.

Prerequisites

Procedure

  1. Change to the directory with library sources.

  2. Compile each source file to an object file with the position-independent code option -fPIC: 

    $ gcc ... -c -fPIC some_file.c ...
    Copy to Clipboard Toggle word wrap

    The object files have the same file names as the original source code files, but their extension is .o.

  3. Link the shared library from the object files: 

    $ gcc -shared -o libfoo.so.x.y -Wl,-soname,libfoo.so.x some_file.o ...
    Copy to Clipboard Toggle word wrap

    The used major version number is X and the minor version number is Y.

  4. Copy the libfoo.so.x.y file to an appropriate location where the system’s dynamic linker can find it. On Red Hat Enterprise Linux, the directory for libraries is /usr/lib64: 

    # cp libfoo.so.x.y /usr/lib64
    Copy to Clipboard Toggle word wrap

    Note that you need root permissions to manipulate files in this directory.

  5. Create the symlink structure for the soname mechanism: 

    # ln -s libfoo.so.x.y libfoo.so.x
# ln -s libfoo.so.x libfoo.so
    Copy to Clipboard Toggle word wrap

Additional Resources

17.4. Creating Static Libraries with GCC and ar
Copier lien

Creating libraries for static linking is possible through the conversion of object files into a special type of archive file.

Note

Red Hat discourages the use of static linking for security reasons. Use static linking only when necessary, especially against libraries provided by Red Hat. See Section 16.2, “Static and dynamic linking”.

Prerequisites

Procedure

  1. Create intermediate object files with GCC. 

    $ gcc -c source_file.c ...
    Copy to Clipboard Toggle word wrap

    Append more source files as required. The resulting object files share the file name but use the .o file name extension.

  2. Turn the object files into a static library (archive) using the ar tool from the binutils package. 

    $ ar rcs libfoo.a source_file.o ...
    Copy to Clipboard Toggle word wrap

    The file libfoo.a is created.

  3. Use the nm command to inspect the resulting archive: 

    $ nm libfoo.a
    Copy to Clipboard Toggle word wrap
  4. Copy the static library file to the appropriate directory.

  5. When linking against the library, GCC will automatically recognize from the .a file name extension that the library is an archive for static linking. 

    $ gcc ... -lfoo ...
    Copy to Clipboard Toggle word wrap

Additional Resources

  • The Linux manual page for the ar tool: 

    $ man ar
    Copy to Clipboard Toggle word wrap
Retour au début
Red Hat logoGithubredditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance. Découvrez nos récentes mises à jour.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez le Blog Red Hat.

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

Theme

© 2025 Red Hat