On Mon, Jan 13, 2014 at 09:02:00AM -0500, Stephen Gallagher wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 01/13/2014 05:45 AM, Lukas Slebodnik wrote:
> ehlo,
>
> While I was working on symbol maps for ding_libs, I found out two
> declarations of function were misspelled in the public header file.
> It looks like nobody used this function, because symbols in library
> are correct
>
> [root@unused-4-233 ~]# objdump -T /usr/lib64/libcollection.so |
> grep col_insert_unsi 0000000000006d50 g DF .text
> 000000000000003b Base col_insert_unsigned_property_with_ref
> 0000000000006af0 g DF .text 000000000000003a Base
> col_insert_unsigned_property
>
> Problem is fixed with simple replacement s/ng/gn/
>
> I can see a problem. I am not sure if we should bump SONAME,
> because ABI of library is not changed, but API is technically
> changed in imcompatible way (two functions were removed and two
> functions were added). It looks like nobody used this functions,
> because it is impossible to link program with wrong declaration.
>
Yeah, it's an interesting case, but I'm going to say that we should
just treat it as a function addition, not a removal. My thought process:
- From an ABI perspective, no function definitions have been changed.
This is because the exposed functions in the library itself have not
been changed.
- From an API perspective, a function definition with no implementation
was removed, but this has zero effect on the linkage with other
applications.
So I'd treat this like "an internal private function was just promoted
to being a public function". So for handling the version-info, it
should be just treated as a new function and leave it at that. (So,
effective result: collection's version info changes from 3:0:1 to 4:0:2
Ack, with that correction.
Pushed to master, version info will be dealt with separately.