Re: GCC5 library transition for xml-security-c -- needed or not?

[Ferenc Wagner <wferi@niif.hu>]

Jakub Wilk <jwilk@debian.org> writes:

> * Ferenc Wagner <wferi@niif.hu>, 2015-11-26, 19:28:
>
>> I'm packaging a new upstream version of xml-security-c. The previous
>> sid version was 1.7.2-3, which had a transition bug filed for it:
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=791323
>>
>> Simon McVittie tagged it "unreproducible", because he suspected that
>> the exported cxx11 symbols were not part of the API, but "weak
>> symbols for template instantiations".  I agree, because the
>> demangled names (as displayed in the bug report) are not even
>> present in the sources.
>
> I disagree. :) One of the symbols in question is 
>
> std::map<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, int, std::less<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, int> > >::operator[](std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)
>
> which is a verbose way of saying
>
> std::map<std::string, int>::operator[](std::string)
>
> This is an indication that the shared library uses
> std::map<std::string, int> objects somewhere. It might be an
> implementation detail (in which case we're safe) or it might be part
> of the ABI.
>
> If you grep for "std::map<std::string", you'll find this in
> OpenSSLCryptoProvider.hpp:
>
> class DSIG_EXPORT OpenSSLCryptoProvider : public XSECCryptoProvider {
> #ifdef XSEC_OPENSSL_HAVE_EC
>    std::map<std::string,int> m_namedCurveMap;
> #endif
> ...
> }
>
> and in OpenSSLCryptoProvider.cpp:
>
> #ifdef XSEC_OPENSSL_HAVE_EC
> int OpenSSLCryptoProvider::curveNameToNID(const char* curveName) const {
>    std::map<std::string,int>::const_iterator i = m_namedCurveMap.find(curveName);
>    ...
> }
> #endif
>
> In Debian, XSEC_OPENSSL_HAVE_EC is defined, so I conclude that this is
> part of xml-security-c ABI, and GCC 5 did break it, and the transition
> was justified.

Jakub, thanks for spending your time digging into this issue.  I forgot
about this operator[] when I worded my question.  Now I still fail to
follow the last step of your reasoning: how does a change in the
internal representaion of curve names (std::string) break the ABI?

>> On the other hand, the package got an NMU to deal with the
>> transition. Now I think that was unnecessary, but could not look
>> into the issue at that time, thus I didn't object.  So
>> libxml-security-c17v5 was born.
>>
>> Now I'm preparing 1.7.3-1.  This minor version bump won't change the
>> SO version, it stays at 17.  I guess I have to acknowledge the NMU
>> some way.  Should I keep the SO version change introduced by the NMU
>> or not?
>
> The NMU didn't change the SONAME, just the package name. And yes, you
> should keep the new name.
>
> (Even if it turned out that the rename was not necessary, you should
> keep it. Unnecessary transitions is bad, but still better than two
> unnecessary transitions!)

Got it.  This makes my above question irrelevant in practice, so I
prepared https://mentors.debian.net/package/xml-security-c with keeping
the v5 package name.  But neverthelessm if you could instruct me further
with the above, I'd happily learn a little C++ ABI stuff.
-- 
Thanks a lot,
Feri.