Private function nl_strerror_l exported in dynamic lib about libnl HOT 2 CLOSED

libnl3 is split in a core library (libnl-3.so) and protocol specific libraries (libnl-route-3.so, libnl-genl-3.so).

The latter libraries use code from the core library.

Functionsl ike nl_strerror or __flags2str are not in public headers (they are considered private API), but are exported to be of use for the other libraries.

That may not be the nicest solution, but the other solutions have their own downsides. Maybe internal the code that is shared by mutliple libraries should be linked statically instead.

In the referenced bug, the user only updates libnl-route-3, but not libnl-3. That cannot work as it is, as libnl-route-3.so depends on libnl-3.so. It is not intended that you can combine the libraries of differing versions. That is not only the case of internal API like nl_strerror(). libnl-3.so could likewise add a new public symbol that is required by libnl-route-3.so, resulting in the same problem.
As libnl3 has symbol versioning, the packaging system should generate appropriate dependencies.

from libnl.

Ok, thanks for the explanation!

from libnl.