libnl linker versioning is off

[Jan Engelhardt]

On Monday 2014-10-06 13:43, Thomas Haller wrote:
>> > 
>> > appears to have been added (as have others). However, libnl.sym.in was 
>> > not updated to reflect this at all. Whenever symbols are added, a new 
>> > version section is to be appended. One must not add symbols to 
>> > preexisting sections.
>> > 
>> > 	LIBNL_3.2.25 {
>> > 	global:
>> > 		nl_cli_ct_parse_zone;
>> > 	} LIBNL_3.2.24;
>
>This issue would be present since the beginning.
>Why do we need different sections libnl_3.2.* instead
>of one libnl_3?


These sections are used to distinguish between ABIs in the
face of equal SONAMEs.
If there is only one, it will add nothing to distinguish a
libnl-3.2.24 libnl-3.so.200 from a libnl-3.2.25 libnl-3.so.200.

The dynamic linker checks on program startup whether the requested
libraries provide all the sections from which the program draws
symbols.
A program which uses nl_cli_ct_parse_zone would - given my patch -
make ld.so request a symver "LIBNL_3.2.25" (the name does not really
matter) from libnl-3.so.200, and this can only be satisfied on a
system that *actually* provides this symver, which is a libnl-3.2.25
or newer installation.

rpm uses the same logic (and ELF data) to ensure that your system
does not end up mixing a libnl-3.2.24 library with a 25-requesting
program.


(I feel sad having to try and explain this to every project.
Are there ways to generally improve on this, globally?)