Hi, On Sat, 2016-04-02 at 10:41 +0200, Jörg Frings-Fürst wrote: > I have some questions about the handling of symbols files at Debian. > > The quotes based on the package bitz-server[1]. > > My symbols file are[2]: > > [quote] > libicap.so.1 libicap1 #MINVER# > (c++)"icap::RequestHeader::read_header(std::__cxx11::basic_string, std::allocator > const&)@Base" 1.0.0 > (c++)"icap::RequestHeader::RequestHeader(std::__cxx11::basic_string, std::allocator > const&)@Base" 1.0.0 > (c++)"icap::RequestHeader::RequestHeader(std::__cxx11::basic_string, std::allocator > const&)@Base" 1.0.0 > [/quote] [...] > The building at armel[4] fails with: > > [quote] > --- debian/libicap1.symbols (libicap1_1.0.0-1_armel) > +++ dpkg-gensymbols782sDG 2016-02-12 21:11:15.078848642 +0000 > @@ -1,4 +1,6 @@ > libicap.so.1 libicap1 #MINVER# > + _ZSt13__adjust_heapIN9__gnu_cxx17__normal_iteratorIPSt4pairINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEiESt6vectorIS9_SaIS9_EEEEiS9_NS0_5__ops15_Iter_comp_iterIN4icap6Header27encapsulated_header_compareEEEEvT_T0_SM_T1_T2_@Base 1.0.0-1 > + _ZSt16__introsort_loopIN9__gnu_cxx17__normal_iteratorIPSt4pairINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEiESt6vectorIS9_SaIS9_EEEEiNS0_5__ops15_Iter_comp_iterIN4icap6Header27encapsulated_header_compareEEEEvT_SL_T0_T1_@Base 1.0.0-1 > (c++)"__gnu_cxx::__normal_iterator, std::allocator > > std::__find_if<__gnu_cxx::__normal_iterator, std::allocator > >, __gnu_cxx::__ops::_Iter_pred > > >(__gnu_cxx::__normal_iterator, std::allocator > >, __gnu_cxx::__normal_iterator, std::allocator > >, __gnu_cxx::__ops::_Iter_pred > >, std::random_access_iterator_tag)@Base" 1.0.0 > (c++)"icap::Header::Header()@Base" 1.0.0 > (c++)"icap::Header::attach(std::__cxx11::basic_string, std::allocator >, std::__cxx11::basic_string, std::allocator >)@Base" 1.0.0 > @@ -64,18 +66,18 @@ > [/quote] Welcome to the world of C++ template instantiations! C++ has a rule called the One Deinition Rule (ODR). The rule states that there is exactly one definition of every used function (including templates) in an executable. When compiling a normal program, this is solved by compiling the template once for every translation unit it's used, and then the linker contains special support for merging all the definitions into one. When shared objects are used, for every library and executable which uses a function, the linker emits a weak global symbol for it. The dynamic linker then merges all the symbols together so that only one is used. What you're seeing here are these weak template instantiation symbols used to implement the ODR. In theory, any consumers of your library should work whether these symbols are defined or not (since consumers should have an implementation too), so they are not part of the ABI. Since these symbols are usually from the std:: namespace, I generally ignore all of them using a regex which covers most cases (this will obviously fail if your library actually does emit std:: symbols). Something like this handles it: https://sources.debian.net/src/libsfml/2.3.2%2Bdfsg-1/debian/libsfml-system2.3v5.symbols/ James
Attachment:
signature.asc
Description: This is a digitally signed message part