Is symbol versioning widely used in linux libraries or is it just used in some specific and rare cases?

57 Views Asked by At

I'm quoting the following from the popular book "The Linux programming interface" by Michael Kerrisk related to symbol versioning :

"This technique provides an alternative to the traditional library versioning approach of using major and minor version numbers in the shared library real name."

I'd like to know an opinion from some linux library guys who deal with linux shared libraries a lot.

My question is if the symbol versioning technique is just a rare and not commonly used technique in linux shared libraries.

1

There are 1 best solutions below

0
bk2204 On

It is commonly used for shared libraries on distros, principally those for which multiple versions might end up linked into the same binary, such as OpenSSL and libpng.

Take, for example, Git. Git can be built with OpenSSL natively, and it can also link against libcurl, which may use OpenSSL itself. (As a practical matter, distros are forbidden from distributing Git linked against OpenSSL in this way, but it's just an example.) If Git was built against OpenSSL 1.1 and libcurl gets an update to use OpenSSL 3.0, then without symbol versioning, which version of a certain function gets called at runtime is a crapshoot, and the program is probably going to crash.

If you're using symbol versioning, then the OpenSSL 1.1 symbols are distinct from the OpenSSL 3.0 symbols due to the versioning, so everything works just fine. This makes it a lot easier to upgrade software piecemeal instead of having to rebuild everything at once.

Another notable example is glibc, which is effectively always versioned. The memcpy function requires that its arguments do not overlap. glibc, on some architectures, implemented a highly optimized version that copied down instead of up, which is permissible according to the standard. However, some software (notably, at the time, Flash Player), assumed something different because it misused memcpy, and so crashed.

The solution was to leave the old version in place with the old symbol name and create memcpy with a new symbol version. New software would use the new behaviour and get the performance increase, while old software would use the old version and get the copies-up code.

Similarly, Glibc 2.34 added new POSIX semaphore functions and newly compiled software can link against them and get new features, while older software will continue to run without changes.