I do see this bug in both sid and mostly-buster (I haven't tried
creating a new buster chroot). If only some people see this bug, but
who sees it is reproducible, that could be a sign of another problem
such as the package doing build-time hardware detection.
(https://sources.debian.org/src/highwayhash/0%7Egit20190222.276dd7b-1/README.md/#L24
says it provides both build-time-CPU-detection and
run-time-CPU-detection variants.)
It appears to be the same bug as #923255 (which is "arch-specific"
because the expected symbol list was updated for amd64), implying that
if it is caused by a change in other packages, it appeared between
2018-11-26 (gcc 8.2.0-10, glibc 2.27-8, binutils 2.31.1-8) and
2019-02-24 (gcc 8.2.0-21, glibc 2.28-7, binutils 2.21.1-14).
It is one of 4 symbol mismatch bugs (in different packages) found in
this archive rebuild run:
#924840 / #923255 highwayhash
(gdb) demangle
_ZNSt6vectorIjSaIjEE17_M_realloc_insertIJRKjEEEvN9__gnu_cxx17__normal_iteratorIPjS1_EEDpOT_@Base
0~20180209-g14dedec
void std::vector<unsigned int, std::allocator<unsigned int>
>::_M_realloc_insert<unsigned int
const&>(__gnu_cxx::__normal_iterator<unsigned int*, std::vector<unsigned
int, std::allocator<unsigned int> > >, unsigned int const&)@Base
0~20180209-g14dedec
#924849 gatb-core
(gdb) demangle
_ZZN4gatb4core8debruijn4impl5bglueILm96EEEvPNS0_5tools7storage4impl7StorageENSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEiiibENKUlRKNS0_4bank8SequenceEE_clESI_@Base
gatb::core::debruijn::impl::bglue<96ul>(gatb::core::tools::storage::impl::Storage*,
std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> >, int, int, int,
bool)::{lambda(gatb::core::bank::Sequence
const&)#1}::operator()(gatb::core::bank::Sequence const&) const@Base
#924841 lib3mf
(gdb) demangle
_ZNSt8_Rb_treeIjSt4pairIKjSt10shared_ptrIN3NMR14CModelResourceEEESt10_Select1stIS6_ESt4lessIjESaIS6_EE5eraseERS1_@Base
1.8.0+ds
std::_Rb_tree<unsigned int, std::pair<unsigned int const,
std::shared_ptr<NMR::CModelResource> >,
std::_Select1st<std::pair<unsigned int const,
std::shared_ptr<NMR::CModelResource> > >, std::less<unsigned int>,
std::allocator<std::pair<unsigned int const,
std::shared_ptr<NMR::CModelResource> > > >::erase(unsigned int
const&)@Base 1.8.0+ds
#924819 libstatgen
(c++)"void std::vector<float, std::allocator<float>
>::emplace_back<float>(float&&)@Base" 1.0.14
The other 3 were fixed by updating the expected symbols list, and this
one probably could be as well, but that only fixes the FTBFS itself and
not any potential underlying issue.
As highwayhash has no rdeps in sid (it was packaged as a dependency of
tensorflow, which is only in experimental), doing nothing and allowing
it to be removed from buster may also be an option.
