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.
--
Simo Sorce * Red Hat, Inc * New York