-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 05/09/2014 02:37 AM, Lukas Slebodnik wrote:
On (08/05/14 10:08), Stephen Gallagher wrote:
> On 04/14/2014 02:42 AM, Lukas Slebodnik wrote:
>> ehlo,
>>
>> release blocked by:
>>
https://lists.fedorahosted.org/pipermail/sssd-devel/2014-April/019043.html
>>
>>
>>
Two patches are attachd.
>>
>> My notes: basicobject no ABI change new function added
>> simplebuffer_get_vbuf libref_array no ABI change function
>> ref_array_debug added to public header ref_array.h
>>
>> libcollection version-info should be 4:0:0, but there would be
>> big jump in soname libcollection.so.2.1.0 ->
>> libcollection.so.4.0.0
>>
>> -function removed from ABI: col_allocate_item (declared in
>> collection_priv.h)
>>
>> libini_config version-info should be 5:0:0, but there would be
>> big jump in soname libini_config.so.3.1.0 ->
>> libini_config.so.5.0.0
>>
>> -functions removed from ABI:collect_metadata, empty_section,
>> ini_boundary_cb, ini_cleanup_cb, ini_comment_cb,
>> ini_get_error_str,is_allowed_spaces. is_just_spaces,
>> parser_run, prepare_metadata, print_grammar_errors,
>> print_validation_errors, read_line, valid_collision_flags
>> //were declared in internal ini_metadata.h or
>> ini_config_priv.h
>>
>
> Patch 0001:
>
> libpath_utils: ack libdhash: ack libcollection: I had a
> discussion with Lukas on IRC about this. This was a premature
> optimization. We should follow the version-info update rules
> here, regardless of the jump in soname to so.4. The reason for
> this is that the meaning of the previous 2.1.0 version was this:
> "This library can support clients that are talking version 2 of
> the ABI as well as version 3 (the second value is the number of
> additional interface revisions beyond it).
>
> However, when we created ABI version 4, we *removed* some
> functions. This means we are no longer capable of meeting the
> needs of clients expecting versions 2 and 3, so we have to set
> the minimum version to 4 and re-set the second value to zero (for
> future use if we add an ABI version 5). In theory, we could
> someday go from 4.99.0 directly to 103.0.0, which would be a much
> larger jump and it would still be a *correct* answer.
>
> So the correct version-info here is 4:0:0
fixed
>
> Also, I'm not familiar enough with symbol table files. Why are
> you moving col_destroy_collection_with_cb out of a separate
> section in the symbol table? Shouldn't they remain distinct for
> historical reasons?
If you link program with some library without version symbols the
linker requires only SONAME
sh$ objdump -p /usr/sbin/sssd //snip Dynamic Section: NEEDED
libtevent.so.0 NEEDED libtalloc.so.2 NEEDED
libpopt.so.0 NEEDED libldb.so.1 ...
The version symbol files are usefull if you want to require newer
version of library, which didn't change SONAME (only minor version
was updated)
If SONAME was bumped you have to recompile your program with newer
version of library otherwise you will not be able to start program.
The symbol versioning will not help in this case, you can merge all
symbols to the one version.
sh$ objdump -p /usr/sbin/sssd //snip Version References: required
from libtalloc.so.2: 0x0ea30422 0x00 04 TALLOC_2.0.2 required from
libkeyutils.so.1: 0x0ae3c993 0x00 06 KEYUTILS_0.3 required from
libpthread.so.0: 0x09691a75 0x00 05 GLIBC_2.2.5 required from
libc.so.6: 0x0d696913 0x00 11 GLIBC_2.3 0x09691a75 0x00 03
GLIBC_2.2.5 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ functions with two
different version of glibc are required. It is automatically
detected by linker.
//side note. It is possible to do backward incompatible change with
symbol versioning. But we didn't released ding-libs with them yet,
therefore we can modify them without any probelm
sh$ objdump -T /lib64/libc.so.6 | grep " realpath" 0000003ce1d302b0
g DF .text 0000000000000021 (GLIBC_2.2.5) realpath
0000003ce1c42e50 g DF .text 0000000000000523 GLIBC_2.3
realpath
> Maybe I just don't understand this area enough.
More about symbol versioning
http://www.redhat.com/f/summitfiles/presentation/June2/Developer%20Tools/...
>
>
>
> ini_config: we need to be using 5:0:0 for version-info.
fixed.
Thank you very much for review. New patches are attached.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird -
http://www.enigmail.net/
iEYEARECAAYFAlNszasACgkQeiVVYja6o6Nu9gCbB9lb0pvbb/+AitUJx+xtMarK
evsAoJB0zJ8fnm2nWKTTPD4iN+TRywpg
=2+Em
-----END PGP SIGNATURE-----