Add shared library versioning support

[quanah]

It would be useful to have shared library versioning added to libevent to avoid namespace issues if different versions of libevent are present in the root namespace.

See https://www.gnu.org/software/gnulib/manual/html_node/LD-Version-Scripts.html and https://www.akkadia.org/drepper/dsohowto.pdf

[ploxiln]

Libevent already bumps "soname" after backwards-incompatible releases, this helps to link the correct version of libevent if multiple are installed in a system. The primary use of symbol versioning is to for a single newer libevent to offer older versions of some functions, for binaries that were built against the older libevent, assuming that the older libevent already had symbol versioning, and the new version wants to change these functions ABI while keeping the same API (e.g. via header macros). I have also seen symbol versioning used for jansson and json-c to disambiguate conflicting functions named json_*() when they are used by different libraries that are used by the same binary. (In this case they don't use versions, just @jansson / @json-c.)

It appears that you are trying to link multiple different-version copies of libevent into the same binary. I don't think anyone should try to do that.

[quanah]

No, that's not what I'm trying to do. I'm trying to use my own locally compiled version of libevent and don't want it to clash with the distro provided libevent if it's loaded into the root namespace.

[ploxiln]

I'm still not sure what "root namespace" is in this context, but to use your own locally compiled libevent instead of your system libevent, you just need to build and install libevent with ./configure --prefix=/home/me/wherever (or cmake equivalent I can never remember), and then build other software with PKG_CONFIG_FLAGS=/home/me/wherever/lib/pkgconfig or CFLAGS=-I/home/me/wherever/include and LDFLAGS=-L/home/me/wherever/lib.

[quanah]

It has to do with the namespace for running processes.

Here's a dated but quick example. When OpenLDAP 2.4 was released, most distributions at that time only shipped software linked to the OpenLDAP 2.3 libraries. If two processes were running that were each linked to a different version of the OpenLDAP libraries, regardless of the fact that the so library name was bumped, the symbols for both the 2.3 and 2.4 OpenLDAP libraries would end up in process namespace, collisions would occur, and mayhem would ensue. This issue particularly affects debian based distributions because they load all libraries into the root namespace regardless of what local user the process(es) are running as. So for example, if someone had an OpenLDAP 2.4 build version of the slapd process (the openldap daemon), and a 2.3 linked version of sssd running, both libraries would end up in the root namespace, and there would be conflicts. Symbol versioning can be used to avoid this problem. My issue is that I will be providing a piece of software to our end users that links to libevent 2.1 while the distro provided libevent is 2.0. I need to ensure mayhem does not ensue.

[ploxiln]

It appears that you are trying to link multiple different-version copies of libevent into the same binary.

It seems this is the case you are worrying about.

If two processes were running that were each linked to a different version of the OpenLDAP libraries

This should be totally fine. Two separate processes loading two different versions of libevent are no problem, if they are indeed separate processes. They do not share a "root namespace" of loaded shared libraries.

But it sounds like in the openldap case there was a single process somewhere that ended up with both versions of openldap libraries loaded, I'm guessing due to some plugin system. Maybe some main program linked against one version, and loaded plugins, and a plugin linked against the other version. Or two different plugins linked against different versions.

[ploxiln]

(I'm guessing that may have been due to nss_ldap, a glibc user resolver plugin, which could be linked into practically all processes in the system if glibc loads it. libevent won't have this problem.)

[quanah]

(I'm guessing that may have been due to nss_ldap, a glibc user resolver plugin, which could be linked into practically all processes in the system if glibc loads it. libevent won't have this problem.)

No, that's not it. Again, it's any two processes, I simply picked sssd as an example. It could be a perl client instead of SSSD, that's linked to Net::LDAPapi. Or a python client linked to python-ldap.

There's even more to it. For example, libcurl adds to its symbol map whether it was linked to OpenSSL or GnuTLS so that two different programs that are linked to the same release of libcurl, but where the libcurl libraries were linked to two different TLS implementations, won't clash. Same problem can happen if it's two different versions of OpenSSL (say 1.0.2 and 1.1.1), which is why OpenSSL has also added symbol versioning.

[quanah]

This should be totally fine. Two separate processes loading two different versions of libevent are no problem, if they are indeed separate processes. They do not share a "root namespace" of loaded shared libraries.

And this is where you're incorrect. On Debian based OSes, they do, in fact, share the same root namespace of symbols, even though they are completely separate processes.

[ploxiln]

Debian is the same as other linux systems. The "namespace of symbols" is only shared among libraries loaded into a process, two separate processes need not share any libraries. The extreme case of this is containers. These are normal processes all visible in the root process namespace, but with separate views of the filesystem, they can load completely independent sets of libraries from different linux distros. But you don't need containers to get a similar effect.

• You can statically link all needed libraries including libc (particularly using musl-libc which doesn't use resolver plugins)
• You can statically link all libraries besides libc (as long as they do not share symbols with libraries linked by glibc resolver plugins, which most of them don't)
• You can link with a custom rpath or run with a custom LD_LIBRARY_PATH to a directory where you have built+installed all needed libraries for your program. No other system programs will find and link to your custom libraries if this is a non-standard directory.

I've personally done this a few times, in one case for an application using libevent, openssl, libwebsockets, and jansson. Nothing on the system uses my libraries, and my application does not use any system libraries besides glibc.

What you ask for would be needed by any and every library, meanwhile this usage of symbol versioning is extremely rare. If you have this problem, symbol versioning is not the solution. You can probably just do a static-only build of libevent and statically link your thing to it. This would work even if your thing is a plugin to be loaded by arbitrary processes by your customers.

(It sounds like maybe that's what your making, a shared library or plugin that is loaded into arbitrary other processes by your customers? which may load libperl and perl modules, or libpython and python packages?)

[azat]

Providing namespace support (like i.e. jemalloc does) is too much for libevent, unless there will be show some examples of real conflicts.