Chapter 4. Creating libraries with GCC
This chapter describes steps for creating libraries and explains the necessary concepts used by the Linux operating system for libraries.
4.1. Library naming conventions
A special file name convention is used for libraries: a library known as foo is expected to exist as 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 ...
-
When creating the library, the full file name
libfoo.so
orlibfoo.a
must be specified.
Additional resources
4.2. The soname mechanism
Dynamically loaded libraries (shared objects) use a mechanism called soname to manage multiple compatible versions of a library.
Prerequisites
- You must understand dynamic linking and libraries.
- You must understand the concept of ABI compatibility.
- You must understand library naming conventions.
- You must understand symbolic links.
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:
- Identification of the actual version of the library
- Need for multiple versions of the same library present
- Signalling ABI compatibility of each of the multiple versions
The soname mechanism
To resolve this, Linux uses a mechanism called soname.
A foo
library version X.Y is ABI-compatible with other versions with the same value of X in a version number. Minor changes preserving compatibility increase the number Y. Major changes that break compatibility increase the number X.
The actual foo
library version X.Y exists as a file libfoo.so.x.y
. Inside the library file, a soname is recorded with 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 that declares dependency on the library using the soname, not a name or a file name.
When the runtime dynamic linker links an application before running, it reads the soname from application’s executable file. 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 a version, because the soname does not change.
The Y component of the version number is not limited to just a single number. Additionally, some libraries encode their version in their name.
Reading soname from a file
To display the soname of a library file somelibrary
:
$ objdump -p somelibrary | grep SONAME
Replace somelibrary with the actual file name of the library you wish to examine.
4.3. Creating dynamic libraries with GCC
Dynamically linked libraries (shared objects) allow:
- resource conservation through code reuse
- increased security by making it easier to update the library code
Follow these steps to build and install a dynamic library from source.
Prerequisites
- You must understand the soname mechanism.
- GCC must be installed on the system.
- You must have source code for a library.
Procedure
- Change to the directory with library sources.
Compile each source file to an object file with the Position independent code option
-fPIC
:$ gcc ... -c -fPIC some_file.c ...
The object files have the same file names as the original source code files, but their extension is
.o
.Link the shared library from the object files:
$ gcc -shared -o libfoo.so.x.y -Wl,-soname,libfoo.so.x some_file.o ...
The used major version number is X and minor version number Y.
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
Note that you need root permissions to manipulate files in this directory.
Create the symlink structure for soname mechanism:
# ln -s libfoo.so.x.y libfoo.so.x # ln -s libfoo.so.x libfoo.so
Additional resources
- The Linux Documentation Project — Program Library HOWTO — 3. Shared Libraries
4.4. Creating static libraries with GCC and ar
Creating libraries for static linking is possible through conversion of object files into a special type of archive file.
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 3.2, “Static and dynamic linking” for more details.
Prerequisites
- GCC and binutils must be installed on the system.
- You must understand static and dynamic linking.
- Source file(s) with functions to be shared as a library are available.
Procedure
Create intermediate object files with GCC.
$ gcc -c source_file.c ...
Append more source files if required. The resulting object files share the file name but use the
.o
file name extension.Turn the object files into a static library (archive) using the
ar
tool from thebinutils
package.$ ar rcs libfoo.a source_file.o ...
File
libfoo.a
is created.Use the
nm
command to inspect the resulting archive:$ nm libfoo.a
- Copy the static library file to the appropriate directory.
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 ...
Additional resources
Linux manual page for ar(1):
$ man ar