On Mon, Jul 23, 2018 at 02:41:29PM +0200, Mattia Rizzolo wrote:
> > [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=897780
>
> Looking at that bug, the 7 new symbols that appeared are of that
> category I was talking about (looking at the unmangled naming that
> c++filt reports they are things like:
>
> + std::_Rb_tree_iterator<std::pair<int const,
> std::vector<std::__cxx11::basic_string<char, std::char_traits<char>,
> std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> > > > > > std::_Rb_tree<int,
> std::pair<int const, std::vector<std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> >,
> std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>,
> std::allocator<char> > > > >, std::_Select1st<std::pair<int const,
> std::vector<std::__cxx11::basic_string<char, std::char_traits<char>,
> std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> > > > > >, std::greater<int>,
> std::allocator<std::pair<int const,
> std::vector<std::__cxx11::basic_string<char, std::char_traits<char>,
> std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> > > > > >
> >::_M_emplace_hint_unique<std::piecewise_construct_t const&,
> std::tuple<int&&>, std::tuple<> >(std::_Rb_tree_const_iterator<std::pair<int
> const, std::vector<std::__cxx11::basic_string<char, std::char_traits<char>,
> std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> > > > > >,
> std::piecewise_construct_t const&, std::tuple<int&&>&&, std::tuple<>&&)@Base
> 2.4.0-3
>
> which is ... not something people should usually care about…), and if
> added they should have the '(optional)' tag (incidentally, it feels to me
> that also all the surrounding symbols should). However, that's not the
> error, dpkg-gensymbols wouldn't fail for new symbols by default, but
> only if some disappear: you should check the ones that disappeared.
OK, maintainer in CC.
> Also, I noticed the rules file is doing some funky renaming to have the
> symbols file apply only on amd64. I recommend you go read
> dpkg-gensymbols(1) and discover architecture-specific symbols file.
This was actually my recommendation following an "the perfect is the
enemy of the good" principle. We checked the possibility of having
architecture-specific symbols files for all libbpp* libs. However, it
turned out that the effort to maintain this would be at least one order
of magnitude higher than every other maintenance work for these
packages. Since having symbols files on amd64 in principle serves the
purpose of detecting ABI changes and the software is in practice used
only here I suggested this solution to the maintainer (who is also
upstream). (This should be somewhere recorded on one Debian Med list -
I'm to offline-ish currently to seek for this.)
Kind regards
Andreas.
--
http://fam-tille.de
