Bug#924840: highwayhash: FTBFS - symbol missing

Rebecca N. Palmer rebecca_palmer at zoho.com
Sun Apr 7 15:05:00 BST 2019


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_ at 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_ at 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 at Base
#924841 lib3mf
(gdb) demangle 
_ZNSt8_Rb_treeIjSt4pairIKjSt10shared_ptrIN3NMR14CModelResourceEEESt10_Select1stIS6_ESt4lessIjESaIS6_EE5eraseERS1_ at 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.



More information about the debian-science-maintainers mailing list