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
LS
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
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
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? Maybe I just don't understand this area enough.
ini_config: we need to be using 5:0:0 for version-info.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 05/08/2014 10:08 AM, Stephen Gallagher wrote:
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.104.0.0 I meant, of course.
"There are two hard problems in computer science: cache validation, variable substitution, and off-by-one errors."
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/Dre... 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
-----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/Dre...
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.
Ack
On (09/05/14 08:44), Stephen Gallagher wrote:
-----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/Dre...
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.
Ack
Thank you very much for review.
LS
sssd-devel@lists.fedorahosted.org
-
Jakub Hrozek -
Lukas Slebodnik -
Stephen Gallagher