libnl linker versioning is off

[Thomas Haller]

On Mon, 2014-10-06 at 14:37 +0200, Jan Engelhardt wrote:
> 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 -


It seems Thomas didn't forward the mentioned patch. If one of you two
could forward it to the mailing list... (thanks).


> 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?)

Thanks for taking the effort. Some well-written Howto on the internet
would seem helpful.


Thomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/libnl/attachments/20141006/0d5431cb/attachment.sig>