Symbol `SSL_ImplementedCiphers' has different size in shared object, consider re-linking

[Simo Sorce]

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