Re: Handling of symbols file on Debian build
* Jörg Frings-Fürst , 2016-04-02, 10:41: The result looks like that all builds use an other symbols file as base, because already the second line differs from the original. Why? Looks like a bug in dpkg-gensymbols(1). You might want to file the bug in the BTS. This circumstance also prevents the simple use of patch. Right, although in this case (as James explained in another mail) the patch wouldn't be useful for direct applying anyway. -- Jakub Wilk
Re: Handling of symbols file on Debian build
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 + > @@ -1,4 +1,6 @@ > libicap.so.1 libicap1 #MINVER# > + > _ZSt13__adjust_heapIN9__gnu_cxx17__normal_iteratorIPSt4pairINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEiESt6vectorIS9_SaIS9_iS9_NS0_5__ops15_Iter_comp_iterIN4icap6Header27encapsulated_header_comparevT_T0_SM_T1_T2_@Base > 1.0.0-1 > + > _ZSt16__introsort_loopIN9__gnu_cxx17__normal_iteratorIPSt4pairINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEiESt6vectorIS9_SaIS9_iNS0_5__ops15_Iter_comp_iterIN4icap6Header27encapsulated_header_comparevT_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 signature.asc Description: This is a digitally signed message part
Handling of symbols file on Debian build
Hello, 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 result after building the amd64 binaries are[3]: [quote] libicap.so.1 libicap1 #MINVER# _ZN4icap13RequestHeader11read_headerERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE@Base 1.0.0 _ZN4icap13RequestHeaderC1ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE@Base 1.0.0 _ZN4icap13RequestHeaderC2ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE@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 + @@ -1,4 +1,6 @@ libicap.so.1 libicap1 #MINVER# + _ZSt13__adjust_heapIN9__gnu_cxx17__normal_iteratorIPSt4pairINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEiESt6vectorIS9_SaIS9_iS9_NS0_5__ops15_Iter_comp_iterIN4icap6Header27encapsulated_header_comparevT_T0_SM_T1_T2_@Base 1.0.0-1 + _ZSt16__introsort_loopIN9__gnu_cxx17__normal_iteratorIPSt4pairINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEiESt6vectorIS9_SaIS9_iNS0_5__ops15_Iter_comp_iterIN4icap6Header27encapsulated_header_comparevT_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] The result looks like that all builds use an other symbols file as base, because already the second line differs from the original. Why? And from where comes the used symbols file? This circumstance also prevents the simple use of patch. Is there a plan to change it? And what is the best way to maintain it? Nice Weekend.. CU Jörg [1] https://tracker.debian.org/pkg/bitz-server [2] http://httpredir.debian.org/debian/pool/main/b/bitz-server/bitz-server_1.0.0-1.dsc [3] http://ftp.de.debian.org/debian/pool/main/b/bitz-server/libicap1_1.0.0-1_amd64.deb [4] https://buildd.debian.org/status/fetch.php?pkg=bitz-server&arch=armel&ver=1.0.0-1&stamp=1455311478 -- New: GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB 30EE 09F8 9F3C 8CA1 D25D GPG key (long) : 09F89F3C8CA1D25D GPG Key: 8CA1D25D CAcert Key S/N : 0E:D4:56 Old pgp Key: BE581B6E (revoked since 2014-12-31). Jörg Frings-Fürst D-54538 Bausendorf Threema: SYR8SJXB IRC: j_...@freenode.net j_...@oftc.net My wish list: - Please send me a picture from the nature at your home. signature.asc Description: This is a digitally signed message part
