Symbols files for C++ libraries
Hi, for the "casacore" package (written in C++), we wanted to introduce symbols files for the shared libraries it produces. However, this somehow does not work, as they seem to depend on the architecture and/or the C++ compiler version: https://buildd.debian.org/status/logs.php?pkg=casacore&ver=3.2.1-1 shows the build failures for the same package that compiled well on x86_64 caused by differences in the symbols table. How should one handle this? Best regards Ole
Re: Symbols files for C++ libraries
On Fri, Dec 06, 2019 at 05:37:25PM +0100, Ole Streicher wrote: > Hi, > > for the "casacore" package (written in C++), we wanted to introduce > symbols files for the shared libraries it produces. However, this > somehow does not work, as they seem to depend on the architecture and/or > the C++ compiler version: > > https://buildd.debian.org/status/logs.php?pkg=casacore&ver=3.2.1-1 > > shows the build failures for the same package that compiled well on > x86_64 caused by differences in the symbols table. > > How should one handle this? My favorite answer for that is in the Policy section 8.6: """ For most C libraries, the additional detail required by symbols files is not too difficult to maintain. However, maintaining exhaustive symbols information for a C++ library can be quite onerous, so shlibs files may be more appropriate for most C++ libraries. """ If you still want symbols there is pkgkde-gensymbols(1) in pkg-kde-tools and maybe other options. -- WBR, wRAR signature.asc Description: PGP signature
Re: Symbols files for C++ libraries
Am 06.12.2019 um 17:37 schrieb Ole Streicher: How should one handle this? Best regards Ole Arch dependend symbols are a pain in the ... :D there are some approaches to handle it - one could have a look into the KDE packaging tools and packaging how the KDE team handle this. I use a different approach in LXQt - i mangle and sort the symbols and make them unique afterwards. After that i mark symbols that are not in every architecture as optional and when in good mood i list the architectures (positive or negative) Example: (c++)"std::__detail::_Map_basestd::char_traits, std::allocator >, std::pair, std::allocator > const, Fm::FileInfoList>, std::allocatorstd::char_traits, std::allocator > const, Fm::FileInfoList> >, std::__detail::_Select1st, std::equal_to, std::allocator > >, std::hashstd::char_traits, std::allocator > >, std::__detail::_Mod_range_hashing, std::__detail::_Default_ranged_hash, std::__detail::_Prime_rehash_policy, std::__detail::_Hashtable_traits, true>::operator[](std::__cxx11::basic_stringstd::char_traits, std::allocator >&&)@Base" 0.13.0~ (optional|c++)"std::pair, bool> std::_Rb_tree, std::less, std::allocator >::_M_insert_unique(unsigned int&&)@Base" 0.14.1~ (c++)"std::unique_ptr >::~unique_ptr()@Base" 0.14.0~ (c++)"std::vectorstd::allocator >::_M_erase(__gnu_cxx::__normal_iteratorstd::vector > >)@Base" 0.12.0 (optional|c++|arch= !i386 !mips !mipsel !s390x !alpha !hurd-i386 !powerpc !ppc64 )"std::vectorstd::allocator >::_M_erase(__gnu_cxx::__normal_iteratorstd::vector > >)@Base" 0.14.0~ the very simple tool in lxqt-build-tools is symmangle - it create *.mangled files that can be compared with or used as symbols files after minimal changes, cheers Alf
Re: Symbols files for C++ libraries
Andrey Rahmatullin writes: > On Fri, Dec 06, 2019 at 05:37:25PM +0100, Ole Streicher wrote: >> for the "casacore" package (written in C++), we wanted to introduce >> symbols files for the shared libraries it produces. However, this >> somehow does not work, as they seem to depend on the architecture and/or >> the C++ compiler version: >> >> https://buildd.debian.org/status/logs.php?pkg=casacore&ver=3.2.1-1 >> >> shows the build failures for the same package that compiled well on >> x86_64 caused by differences in the symbols table. >> >> How should one handle this? > My favorite answer for that is in the Policy section 8.6: > > """ > For most C libraries, the additional detail required by symbols files is > not too difficult to maintain. However, maintaining exhaustive symbols > information for a C++ library can be quite onerous, so shlibs files may be > more appropriate for most C++ libraries. > """ OK, I think I will just omit symbols file. Casacore anyway changes the ABI quite often, making these files of limited use only. Thank you Ole
Build dependencies not being installed when building postfix for stretch
I am trying to build the postfix Debian package from the stretch sources. I downloaded the .dsc, .orig.tar.gz, and ..debian.tar.xz files and did a "gbp import-dsc *.dsc". When I run "gbp buildpackage --git-dist=stretch" I get this: test -f debian/rules dh_clean build dh_clean: Compatibility levels before 9 are deprecated (level 7 in use) test ! -d debian/postfix || rm -rf debian/postfix /usr/bin/make tidy make[1]: Entering directory '/srv/scratch/postfix-build/postfix' /usr/bin/make -f Makefile.in MAKELEVEL= Makefiles make: Entering directory '/srv/scratch/postfix-build/postfix' (echo "# Do not edit -- this file documents how Postfix was built for your machine."; /bin/sh makedefs) >makedefs.tmp No include file found. Install the appropriate db*-devel package first. make: *** [Makefile.in:32: Makefiles] Error 1 make: Leaving directory '/srv/scratch/postfix-build/postfix' make[1]: *** [Makefile:22: Makefiles] Error 2 make[1]: Leaving directory '/srv/scratch/postfix-build/postfix' make: *** [debian/rules:281: clean-preunpatch] Error 2 gbp:error: 'fakeroot debian/rules clean' failed: it exited with 2 Usually when I build the build process installs any missing packages in the list of build dependencies, but it is not doing that here. Here is my .gbb.conf: [DEFAULT] builder = git-pbuilder cleaner = fakeroot debian/rules clean pristine-tar = True [buildpackage] export-dir = ../build-area/ tarball-dir = .. [import-orig] dch = False
Re: Build dependencies not being installed when building postfix for stretch
git-pbuilder builds in a chroot, containing build-essential and the
build dependencies. (One reason for doing this is to have _only_ those
packages available, and not anything else you happen to have installed,
as a check that the declared build dependencies do include everything
needed.)
However, before entering the chroot, it tries to run debian/rules clean
*outside* the chroot; in some cases the clean step needs some of the
build dependencies, so this can fail.
I'm not sure if this should be considered a bug, but this is what I use
to turn it off:
--- a/usr/bin/pdebuild
+++ b/usr/bin/pdebuild
@@ -85,9 +85,9 @@ else
# eval is needed to reverse that.
SOURCE_OPTIONS=$(get_source_options)
eval dpkg-source ${SOURCE_OPTIONS} --before-build .
-if should_clean_source; then
-"${BUILDSOURCEROOTCMD}" debian/rules clean
-fi
+#if should_clean_source; then
+#"${BUILDSOURCEROOTCMD}" debian/rules clean
+#fi
eval dpkg-source ${SOURCE_OPTIONS} -b .
if ! [ "../${DSC}" -ef "${BUILDRESULT}/${DSC}" ]; then
log.i "Generating source changes file for original dsc"
