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/...
http://www.akkadia.org/drepper/dsohowto.pdf
ini_config: we need to be using 5:0:0 for version-info.
fixed.
Thank you very much for review.
New patches are attached.
LS