Linking shared objects linux

Examples of Shared Object Filenames

Let’s take a look at some examples of shared object filenames to see how they work.

libcrypto.so.1.1

This filename indicates that file is a shared library called «crypto». major version number is 1, and minor version number is 1. This indicates that this is first major version of library and that there have been some minor changes to API or ABI.

libssl.so.1.1

This filename indicates that file is a shared library called «ssl». major version number is 1, and minor version number is 1. This indicates that this is first major version of library and that there have been some minor changes to API or ABI.

libX11.so.6

This filename indicates that file is a shared library called «X11». major version number is 6, and minor version number is 0. This indicates that this is sixth major version of library and that there have been no minor changes to API or ABI.

libgtk-3.so.0

This filename indicates that file is a shared library called «gtk-3». major version number is 0, and minor version number is 0. This indicates that this is first major version of library and that there have been no minor changes to API or ABI.

How Shared Object Files are Found

Shared objects are searched for and loaded by dynamic linker at runtime. dynamic linker is responsible for resolving symbols and linking shared objects with rest of program.

The dynamic linker searches for shared objects in several directories, including −

• /lib
• /usr
• /usr/local/lib
• Directories listed in LD_LIBRARY_PATH environment variable

When a program is compiled, it includes a list of shared object dependencies that it requires to run. When program is executed, dynamic linker searches for these dependencies in directories listed above. If it finds required shared objects, it loads them into memory and links them with program.

If required shared objects are not found, program will fail to run, and an error message will be displayed. To resolve this issue, you can install missing shared objects or add directory containing missing shared objects to LD_LIBRARY_PATH environment variable.

Benefits of Shared Objects

Shared objects provide several benefits over static libraries, including −

• Reduced memory usage − Shared objects are loaded into memory only when they are needed, reducing amount of memory needed to run a program.
• Dynamic linking − Shared objects allow programs to link with libraries at runtime, enabling them to adapt to changes in environment and load libraries only when they are required.
• Code reusability − Shared objects allow developers to reuse code across different programs, reducing development time and improving code maintainability.
• Faster program startup − Shared objects are loaded only when they are needed, reducing program startup time and improving program performance.

Major vs. Minor Version Numbers

The major and minor version numbers in shared object filenames provide information about compatibility of library with other programs. A change in major version number indicates a significant change in API or ABI of library. Programs that use old version of library may not be compatible with new version.

A change in minor version number indicates a small change in API or ABI of library. Programs that use old version of library should still be compatible with new version, but may not be able to take advantage of new features or improvements in library.

Managing Shared Objects

Managing shared objects in Linux can be challenging, particularly when dealing with dependencies between libraries. Here are some tips for managing shared objects in Linux −

• Use package managers − Most Linux distributions come with package managers that allow you to install and manage shared objects and their dependencies. Using a package manager can help ensure that your system is up-to-date and that you have all necessary dependencies.
• Avoid modifying system directories − Modifying system directories such as /lib and /usr can cause issues with dynamic linker and may break other programs. Instead, install shared objects in directories such as /usr/local/lib or in your home directory.
• Use symbolic links − If you have multiple versions of a shared object, you can use symbolic links to point to current version. This can help ensure that programs that depend on shared object can still find it even if version number changes.
• Check LD_LIBRARY_PATH − If you are experiencing issues with missing shared objects, check LD_LIBRARY_PATH environment variable to ensure that it includes directories containing required shared objects.

Conclusion

Shared objects are an essential part of Linux operating system. They allow programs to share code and data between processes, reducing size of executable files and amount of memory needed to run a program. Shared object filenames in Linux follow a specific naming convention that provides information about file’s contents, including name of library, major and minor version numbers, and file type. dynamic linker searches for shared objects at runtime in several directories, including /lib, /usr, and directories listed in LD_LIBRARY_PATH environment variable. Understanding how shared object filenames work is crucial for developing and running Linux programs efficiently.

Источник

How to make and manage shared objects in GNU/Linux environment

For scalability, evolutivity and debug purposes, it is interesting to make applications be based on add-ons. The shared object concept which comes along with the GNU/Linux environment can achieve it.

• Implicitly by gathering the shared objects in some directories and make the system load and link them automatically at program startup;
• Explicitly by making the program load and link the shared objects thanks to some library services (i.e. libdl.so).

For the following examples, we use a main program which source file is base.cc or base1.cc and a shared object which source file is base_shared.cc.

We chose very simple C++ written examples instead of C written programs because this is the most general case (C is a subset of C++) and the situation where most of the problems can appear when linking and loading shared objects.

The shared object defines a global C++ class which must be initialized at library loading time and deinitialized at library unloading time. This kind of initialization/deinitialization routines are called static constructors/destructors. Moreover, the shared object offers an entry point (base_initialize()) in C language (to avoid mangling problems) which is called by the main program.

1. Implicit loading/linking of shared objects

The implicit linking consists to start a main program referencing symbols located in some shared objects which are automatically loaded and linked to the main program at startup.

1.1. TEST 1 : Building of shared lib with «ld»

—> Location of the shared libs at program startup :

—> Make the shared library :

> g++ -c base_shared.cc
> ld -shared base_shared.o -o libbase_shared.so

—> Make the main program

> g++ base.cc -L`pwd` -lbase_shared
/usr/bin/ld: a.out : hidden symbole « __dso_handle » in /usr/lib/gcc/i486-linux-gnu/4.1.2/crtbegin.o est référencé par DSO
/usr/bin/ld: édition de lien finale en échec: Section non-représentable pour la sortie
collect2: ld returned 1 exit status

We can see that the linking of the main program fails because of the referencing of a hidden symbol : __dso_handle.

1.2. TEST 2 : Building of shared lib with «gcc»

—> Location of the shared libs at program startup :

—> Make the shared library :

> g++ -c base_shared.cc
> g++ -shared base_shared.o -o libbase_shared.so

—> Make the main program

> g++ base.cc -L`pwd` -lbase_shared

> ./a.out
Constructor of toto
Main entry point
Shared lib entry point, toto’s var = 18
Destructor of toto

We can see that the program is dynamically linked to the shared object. The static constructor and destructor of the shared library are run automatically at loading/unloading time.

2. Explicit loading/linking of shared objects

The explicit linking consists to start a main program referencing symbols located in some shared objects which are loaded and linked to the main program through a call to «dlopen()».

2.1. TEST 1 : Building of shared lib with «ld»

—> Make the shared library :

> g++ -c base_shared.cc
> ld -shared base_shared.o -o libbase_shared.so

—> Make the main program

> g++ base1.cc -ldl

—> Run the program

> ./a.out
Main entry point
./libbase_shared.so: undefined symbol: __dso_handle

We can see that the loading of the shared object fails because of an unresolved symbol : __dso_handle.

2.2. TEST 2 : Building of shared lib with «gcc»

—> Make the shared library :

> g++ -c base_shared.cc
> g++ -shared base_shared.o -o libbase_shared.so

—> Make the main program

> ./a.out
Main entry point
Loading shared lib.
Constructor of toto
Shared lib entry point, toto’s var = 18
Destructor of toto

We can see that the static constructor and destructor of the shared library are run automatically at loading/unloading time (i.e. During the call to «dlopen()»).

Conclusion

Which ever the way we load and link the shared objects (implicitly or explicitly), it appears that the best way to make shared objects is to use «g++ -shared» and not «ld -shared». This makes the shared object prepared to run the static constructors at loading time and the static destructors at unloading time.

Resources

About the author

base.cc

Источник