I update from nss-3.19.3-1.0.fc22.x86_64 to nss-3.20.0-1.0.fc22.x86_64 this morning, and now I get this stderr output:
$ /usr/bin/stap -V >/dev/null /usr/bin/stap: Symbol `SSL_ImplementedCiphers' has different size in shared object, consider re-linking
The message comes from ld.so; that symbol comes from libssl3.so.
Should I be worried about this? Do we need a rebuild of all nss-dependent packages to clear this message?
On 08/28/2015 03:23 PM, Josh Stone wrote:
I update from nss-3.19.3-1.0.fc22.x86_64 to nss-3.20.0-1.0.fc22.x86_64 this morning, and now I get this stderr output:
$ /usr/bin/stap -V >/dev/null /usr/bin/stap: Symbol `SSL_ImplementedCiphers' has different size in shared object, consider re-linking
The message comes from ld.so; that symbol comes from libssl3.so.
Should I be worried about this? Do we need a rebuild of all nss-dependent packages to clear this message?
Well, it's an ABI break. If you care about ABI issues then the change causing the breakage needs reverting and the broken packages need to be rebuilt.
c.
On Pá, 2015-09-04 at 00:38 -0400, Carlos O'Donell wrote:
On 08/28/2015 03:23 PM, Josh Stone wrote:
I update from nss-3.19.3-1.0.fc22.x86_64 to nss-3.20.0-1.0.fc22.x86_64 this morning, and now I get this stderr output:
$ /usr/bin/stap -V >/dev/null /usr/bin/stap: Symbol `SSL_ImplementedCiphers' has different size in shared object, consider re-linking
The message comes from ld.so; that symbol comes from libssl3.so.
Should I be worried about this? Do we need a rebuild of all nss-dependent packages to clear this message?
Well, it's an ABI break. If you care about ABI issues then the change causing the breakage needs reverting and the broken packages need to be rebuilt.
The size of the SSL_ImplementedCiphers array is not part of the public API so it is not really an ABI break in practice. However ld.so of course cannot know that. Is there any way to make the message disappear other than rebuild of the dependent package? I am afraid that unfortunately not.
On Fri, 2015-09-04 at 13:14 +0200, Tomas Mraz wrote:
On Pá, 2015-09-04 at 00:38 -0400, Carlos O'Donell wrote:
On 08/28/2015 03:23 PM, Josh Stone wrote:
I update from nss-3.19.3-1.0.fc22.x86_64 to nss-3.20.0-1.0.fc22.x86_64 this morning, and now I get this stderr output:
$ /usr/bin/stap -V >/dev/null /usr/bin/stap: Symbol `SSL_ImplementedCiphers' has different size in shared object, consider re-linking
The message comes from ld.so; that symbol comes from libssl3.so.
Should I be worried about this? Do we need a rebuild of all nss-dependent packages to clear this message?
Well, it's an ABI break. If you care about ABI issues then the change causing the breakage needs reverting and the broken packages need to be rebuilt.
The size of the SSL_ImplementedCiphers array is not part of the public API so it is not really an ABI break in practice. However ld.so of course cannot know that. Is there any way to make the message disappear other than rebuild of the dependent package? I am afraid that unfortunately not.
If it not public why is it exported in the first place ?
Simo.
On 09/04/2015 03:38 PM, Simo Sorce wrote:
On Fri, 2015-09-04 at 13:14 +0200, Tomas Mraz wrote:
On Pá, 2015-09-04 at 00:38 -0400, Carlos O'Donell wrote:
On 08/28/2015 03:23 PM, Josh Stone wrote:
I update from nss-3.19.3-1.0.fc22.x86_64 to nss-3.20.0-1.0.fc22.x86_64 this morning, and now I get this stderr output:
$ /usr/bin/stap -V >/dev/null /usr/bin/stap: Symbol `SSL_ImplementedCiphers' has different size in shared object, consider re-linking
The message comes from ld.so; that symbol comes from libssl3.so.
Should I be worried about this? Do we need a rebuild of all nss-dependent packages to clear this message?
Well, it's an ABI break. If you care about ABI issues then the change causing the breakage needs reverting and the broken packages need to be rebuilt.
The size of the SSL_ImplementedCiphers array is not part of the public API so it is not really an ABI break in practice. However ld.so of course cannot know that. Is there any way to make the message disappear other than rebuild of the dependent package? I am afraid that unfortunately not.
If it not public why is it exported in the first place ?
The *size* is not part of the ABI, but the symbol is. ELF keeps track of data here which is completely pointless.
There is no way to obtain the actual size of the array from C, so I think the warning could be suppressed using a symbol alias with a constant size.
On Fri, 2015-09-04 at 15:41 +0200, Florian Weimer wrote:
On 09/04/2015 03:38 PM, Simo Sorce wrote:
On Fri, 2015-09-04 at 13:14 +0200, Tomas Mraz wrote:
On Pá, 2015-09-04 at 00:38 -0400, Carlos O'Donell wrote:
On 08/28/2015 03:23 PM, Josh Stone wrote:
I update from nss-3.19.3-1.0.fc22.x86_64 to nss-3.20.0-1.0.fc22.x86_64 this morning, and now I get this stderr output:
$ /usr/bin/stap -V >/dev/null /usr/bin/stap: Symbol `SSL_ImplementedCiphers' has different size in shared object, consider re-linking
The message comes from ld.so; that symbol comes from libssl3.so.
Should I be worried about this? Do we need a rebuild of all nss-dependent packages to clear this message?
Well, it's an ABI break. If you care about ABI issues then the change causing the breakage needs reverting and the broken packages need to be rebuilt.
The size of the SSL_ImplementedCiphers array is not part of the public API so it is not really an ABI break in practice. However ld.so of course cannot know that. Is there any way to make the message disappear other than rebuild of the dependent package? I am afraid that unfortunately not.
If it not public why is it exported in the first place ?
The *size* is not part of the ABI, but the symbol is. ELF keeps track of data here which is completely pointless.
I see, I wonder why not just expose a pointer instead of an array.
There is no way to obtain the actual size of the array from C, so I think the warning could be suppressed using a symbol alias with a constant size.
Would changing the symbol to a pointer break the ABI ? It probably will cause the same kind of warning even though it probably makes no real difference in all the architectures we care about.
Simo.
On Fri, Sep 04, 2015 at 01:14:08PM +0200, Tomas Mraz wrote:
On Pá, 2015-09-04 at 00:38 -0400, Carlos O'Donell wrote:
On 08/28/2015 03:23 PM, Josh Stone wrote:
I update from nss-3.19.3-1.0.fc22.x86_64 to nss-3.20.0-1.0.fc22.x86_64 this morning, and now I get this stderr output:
$ /usr/bin/stap -V >/dev/null /usr/bin/stap: Symbol `SSL_ImplementedCiphers' has different size in shared object, consider re-linking
The message comes from ld.so; that symbol comes from libssl3.so.
Should I be worried about this? Do we need a rebuild of all nss-dependent packages to clear this message?
Well, it's an ABI break. If you care about ABI issues then the change causing the breakage needs reverting and the broken packages need to be rebuilt.
The size of the SSL_ImplementedCiphers array is not part of the public API so it is not really an ABI break in practice. However ld.so of course cannot know that. Is there any way to make the message disappear other than rebuild of the dependent package? I am afraid that unfortunately not.
Clearly it is used by some programs, so it should be considered part of the public API. If it wasn't meant to be exported, it should not have been exported. The ld.so warning is only emitted if there is a copy relocation against that symbol and the symbol has different size in the copy relocation vs. the new size in the shared library.
Jakub
On 09/04/2015 03:49 PM, Jakub Jelinek wrote:
Clearly it is used by some programs, so it should be considered part of the public API. If it wasn't meant to be exported, it should not have been exported. The ld.so warning is only emitted if there is a copy relocation against that symbol and the symbol has different size in the copy relocation vs. the new size in the shared library.
Ugh, I forgot.
Will the process use the size from the shared library, or will the object be truncated, so that when the library tries to traverse the array (using its hard-coded size), it will read past the end of the allocated portion?
On Fri, Sep 04, 2015 at 03:58:12PM +0200, Florian Weimer wrote:
On 09/04/2015 03:49 PM, Jakub Jelinek wrote:
Clearly it is used by some programs, so it should be considered part of the public API. If it wasn't meant to be exported, it should not have been exported. The ld.so warning is only emitted if there is a copy relocation against that symbol and the symbol has different size in the copy relocation vs. the new size in the shared library.
Ugh, I forgot.
Will the process use the size from the shared library, or will the object be truncated, so that when the library tries to traverse the array (using its hard-coded size), it will read past the end of the allocated portion?
It copies the minimum of the two sizes.
Jakub
On 09/04/2015 04:11 PM, Jakub Jelinek wrote:
On Fri, Sep 04, 2015 at 03:58:12PM +0200, Florian Weimer wrote:
On 09/04/2015 03:49 PM, Jakub Jelinek wrote:
Clearly it is used by some programs, so it should be considered part of the public API. If it wasn't meant to be exported, it should not have been exported. The ld.so warning is only emitted if there is a copy relocation against that symbol and the symbol has different size in the copy relocation vs. the new size in the shared library.
Ugh, I forgot.
Will the process use the size from the shared library, or will the object be truncated, so that when the library tries to traverse the array (using its hard-coded size), it will read past the end of the allocated portion?
It copies the minimum of the two sizes.
Do references in other dynamic shared objects matter for determining the final size? Or is this simply between the main program and the library which defines the symbol?
On Fri, Sep 04, 2015 at 05:00:15PM +0200, Florian Weimer wrote:
On 09/04/2015 04:11 PM, Jakub Jelinek wrote:
On Fri, Sep 04, 2015 at 03:58:12PM +0200, Florian Weimer wrote:
On 09/04/2015 03:49 PM, Jakub Jelinek wrote:
Clearly it is used by some programs, so it should be considered part of the public API. If it wasn't meant to be exported, it should not have been exported. The ld.so warning is only emitted if there is a copy relocation against that symbol and the symbol has different size in the copy relocation vs. the new size in the shared library.
Ugh, I forgot.
Will the process use the size from the shared library, or will the object be truncated, so that when the library tries to traverse the array (using its hard-coded size), it will read past the end of the allocated portion?
It copies the minimum of the two sizes.
Do references in other dynamic shared objects matter for determining the final size? Or is this simply between the main program and the library which defines the symbol?
Well, only the program (normal or PIE) and the DSO that defines the symbol matters for determining the size that is copied by the copy relocation of course. But, other DSOs (which do not use copy relocations) will supposedly refer to the definition in the main program, so in this case one with the smaller size (if any).
Jakub
On 09/04/2015 07:11 AM, Jakub Jelinek wrote:
On Fri, Sep 04, 2015 at 03:58:12PM +0200, Florian Weimer wrote:
On 09/04/2015 03:49 PM, Jakub Jelinek wrote:
Clearly it is used by some programs, so it should be considered part of the public API. If it wasn't meant to be exported, it should not have been exported. The ld.so warning is only emitted if there is a copy relocation against that symbol and the symbol has different size in the copy relocation vs. the new size in the shared library.
Ugh, I forgot.
Will the process use the size from the shared library, or will the object be truncated, so that when the library tries to traverse the array (using its hard-coded size), it will read past the end of the allocated portion?
It copies the minimum of the two sizes.
FWIW I found this Mozilla bug which added accessor functions: https://bugzilla.mozilla.org/show_bug.cgi?id=496993
I think the comment about this being "pedantic nonsense" is very wrong, especially since this minimum size copied will not match with reported SSL_NumImplementedCiphers. Or if you rely on the 0-terminating entry of that array, that might not be copied and you'll go off the end.
Anyway, I'll see about porting my code to the accessor functions to sidestep the whole issue.