Re: GCC5 library transition for xml-security-c -- needed or not?
* 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.
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!)
--
Jakub Wilk
Reply to: