Bug#940135: libuhd-dev: uhd.pc missing -lboost_system produces build failures
Is there anything that we can do to help resolving this issue? osmo-trx builds are FTBFS for more than three weeks now, see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=939974 Thanks a lot! Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Bug#940135: libuhd-dev: uhd.pc missing -lboost_system produces build failures
As Pau indicated, we are building a osmo-trx-uhd binary which doesn't use any of boost internally, but simply wants to use UHD. I you remove "-lboost_system" from the UHD pkg-config, all UHD using applications that don't use boost_system internally will fail to link. Normally I would assume that the correct path of action is to remove "-lboost_system" and at the same time introduce a "libboost-system" into the Requires section of pkg-config. However, as boost couldn't be bothered to follow the industry-standard and fails to provide pkg-config files for 12 years (see https://svn.boost.org/trac10/ticket/1094), You cannot use the pkg-config internal dependency mechanism. So my position remains: The patch is wrong, it should be reverted. The application knows it needs UHD. It shouldn't need to track whatever UHD's dependencies to other libraries are today or might become in the future. -- - Harald Welte http://laforge.gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Bug#940135: libuhd-dev: uhd.pc missing -lboost_system produces build failures
osmo-trx.git indeed uses boost, but not all target binaries do. In fact, only osmo-trx-usrp1 does, and it uses it minimally. Only references to boost in code are here: Transceiver52M/device/usrp1/USRPDevice.h 35:#include 36:typedef boost::shared_ptr usrp_standard_tx_sptr; 37:typedef boost::shared_ptr usrp_standard_rx_sptr; However, the build failure happens for osmo-trx-uhd binary target, which uses UHD as a backend but doesn't use boost itself at all: [ 397s] /usr/bin/ld: ./device/uhd/.libs/libdevice.a(UHDDevice.o): undefined reference to symbol '_ZN5boost6system16generic_categoryEv' Related files to UHDDevice.o are: https://git.osmocom.org/osmo-trx/tree/Transceiver52M/device/uhd So unless I'm missing something important, UHDDevice shouldn't be failing to build because it's not explicitly using boost, and boost is only used internally by UHD in there. I'm personally using ArchLinux and in there the patch removing the -lboost_system is not applied. I tried applying the patch on my system (removing -lboost_system from uhd.pc) and osmo-trx-uhd is still building fine on my system (but it seems it doesn't in Debian testing/unstable). I'm using 3.14.1.0-1 on my system. With that patch applied, I see only reference to boost appears while linking osmo-trx-usrp1, which is correct because it's the only one using boost explicitly: """ libtool: link: g++ -I/home/pespin/dev/sysmocom/build/new/out/include/ -I/home/pespin/dev/sysmocom/build/new/out/include/ -I/home/pespin/dev/sysmocom/build/new/out/include/ -g -fno-omit-frame-pointer -fsanitize=address -fsanitize=undefined -o osmo-trx-usrp1 osmo_trx_usrp1-osmo-trx.o -Wl,-rpath -Wl,/usr/lib -Wl,-rpath -Wl,/usr/lib -Wl,-rpath -Wl,/usr/lib ./device/usrp1/.libs/libdevice.a ./.libs/libtransceiver_common.a ../Transceiver52M/arch/x86/.libs/libarch.a ../GSM/.libs/libGSM.a ../CommonLibs/.libs/libcommon.a -L/home/pespin/dev/sysmocom/build/new/out/lib -lfftw3f /home/pespin/dev/sysmocom/build/new/out/lib/libosmoctrl.so /home/pespin/dev/sysmocom/build/new/out/lib/libosmogsm.so -lgnutls /home/pespin/dev/sysmocom/build/new/out/lib/libosmovty.so /home/pespin/dev/sysmocom/build/new/out/lib/libosmocore.so -ltalloc -ldl /home/pespin/dev/sysmocom/build/new/out/lib/libusrp.so -L/usr/lib64 -lboost_thread -lpthread -lboost_system -lusb-1.0 -Wl,-rpath -Wl,/home/pespin/dev/sysmocom/build/new/out/lib -Wl,-rpath -Wl,/home/pespin/dev/sysmocom/build/new/out/lib """ Checking ldd, my libuhd links to libboost_system internally: """ ldd /usr/lib/libuhd.so.3.14.1 | grep boost libboost_chrono.so.1.69.0 => /usr/lib/libboost_chrono.so.1.69.0 (0x7fe729c2f000) libboost_date_time.so.1.69.0 => /usr/lib/libboost_date_time.so.1.69.0 (0x7fe729c1c000) libboost_filesystem.so.1.69.0 => /usr/lib/libboost_filesystem.so.1.69.0 (0x7fe729bfe000) libboost_regex.so.1.69.0 => /usr/lib/libboost_regex.so.1.69.0 (0x7fe729b1e000) libboost_serialization.so.1.69.0 => /usr/lib/libboost_serialization.so.1.69.0 (0x7fe729ada000) libboost_thread.so.1.69.0 => /usr/lib/libboost_thread.so.1.69.0 (0x7fe729ab3000) libboost_system.so.1.69.0 => /usr/lib/libboost_system.so.1.69.0 (0x7fe72932b000) """ And same goes for osmo-trx-uhd (probably inherited by linking to libuhd): """ ldd new/out/bin/osmo-trx-uhd | grep -e boost -e uhd libuhd.so.3.14.1 => /usr/lib/libuhd.so.3.14.1 (0x7f60ce5b) libboost_chrono.so.1.69.0 => /usr/lib/libboost_chrono.so.1.69.0 (0x7f60cd0f8000) libboost_date_time.so.1.69.0 => /usr/lib/libboost_date_time.so.1.69.0 (0x7f60cd0e5000) libboost_filesystem.so.1.69.0 => /usr/lib/libboost_filesystem.so.1.69.0 (0x7f60cd0c7000) libboost_regex.so.1.69.0 => /usr/lib/libboost_regex.so.1.69.0 (0x7f60ccfe5000) libboost_serialization.so.1.69.0 => /usr/lib/libboost_serialization.so.1.69.0 (0x7f60ccfa1000) libboost_thread.so.1.69.0 => /usr/lib/libboost_thread.so.1.69.0 (0x7f60ccf7a000) libboost_system.so.1.69.0 => /usr/lib/libboost_system.so.1.69.0 (0x7f60ccd25000) """ So far my conclusion is that the debian patch is fine (same patch doesn't seem to break build on ArchLinux), but something else is wrong in Debian testing/unstable. Perhaps libuhd is not linked to libboost_system.so there? -- - Pau Espin Pedrol http://www.sysmocom.de/ === * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte
Bug#940135: libuhd-dev: uhd.pc missing -lboost_system produces build failures
Pau Espin Pedrol writes: > osmo-trx fails to build since a few days/weeks ago in Debian testing and > unstable, while it still builds fine in Debian stable. Reported osmo-trx > in Debian can be found in [1] and upstream in [2]. Example of build > failure can be found in Osmocom's OBS repositories for Debian (different > versions available) [3]. ... > Main difference seems to be UHD in testing and stable has this extra patch: > https://sources.debian.org/patches/uhd/3.14.1.0-2/fix-pkg-config/ > > I'm not sure why this patch was applied (I don't see a similar patch > applied in UHD master in upstream). Could it be that libboost-system > doesn't exist on some system architectures but it was unconditionally > dropped with that patch? The reason for the patch was that upstream usage violated this rule: https://lintian.debian.org/tags/pkg-config-references-unknown-shared-library.html Since osmo-trx is using boost itself, it ought to handle its own linking. If -lboost_system is in the Libs.private: field of uhd.pc, does osmo-trx build? UHD has a C API. Having pkg-config output -lboost_system seems wrong in that context. Is this bug better fixed by having osmo-trx handle boost linking? This case is made complicated since UHD exposes boost headers in its headers. And Boost does not provide .pc files. A simple main() that calls uhd::get_version_string() and uhd::get_abi_string() links fine using -luhd alone. Re-reading the pkg-config man page, I think the fix-pkg-config patch on uhd is on the right track. There is a case to be made for for adding "Libs.private: -lboost_system" to uhd.pc, but I do not think that solves the osmo-trx build error (unless building a static binary). -Maitland
Bug#940135: libuhd-dev: uhd.pc missing -lboost_system produces build failures
Package: libuhd-dev Version: 3.14.1.0-2 Severity: important Hi, osmo-trx fails to build since a few days/weeks ago in Debian testing and unstable, while it still builds fine in Debian stable. Reported osmo-trx in Debian can be found in [1] and upstream in [2]. Example of build failure can be found in Osmocom's OBS repositories for Debian (different versions available) [3]. Summary of failure [4]: """ [ 396s] libtool: link: g++ -I/usr/include/ -I/usr/include/ -I/usr/include/ -g -O2 -fdebug-prefix-map=/usr/src/packages/BUILD=. -fstack-protector-strong -Wformat -Werror=format-security -Wl,-z -Wl,relro -Wl,-z -Wl,now -o osmo-trx-uhd osmo_trx_uhd-osmo-trx.o ./device/uhd/.libs/libdevice.a ./.libs/libtransceiver_common.a ../Transceiver52M/arch/x86/.libs/libarch.a ../GSM/.libs/libGSM.a ../CommonLibs/.libs/libcommon.a -lpthread -lfftw3f /usr/lib/x86_64-linux-gnu/libosmoctrl.so /usr/lib/x86_64-linux-gnu/libosmogsm.so -ltalloc /usr/lib/x86_64-linux-gnu/libosmovty.so /usr/lib/x86_64-linux-gnu/libosmocore.so -luhd [ 397s] /usr/bin/ld: ./device/uhd/.libs/libdevice.a(UHDDevice.o): undefined reference to symbol '_ZN5boost6system16generic_categoryEv' [ 397s] /usr/bin/ld: /usr/lib/x86_64-linux-gnu/libboost_system.so.1.67.0: error adding symbols: DSO missing from command line [ 397s] collect2: error: ld returned 1 exit status [ 397s] make[4]: *** [Makefile:681: osmo-trx-uhd] Error 1 """ UHD version in stable (building fine): 3.13.1.0-3 , https://packages.debian.org/stable/libuhd-dev UHD version in testing/unstable (build failure): 3.14.1.0-2 , https://packages.debian.org/stable/libuhd-dev Main difference seems to be UHD in testing and stable has this extra patch: https://sources.debian.org/patches/uhd/3.14.1.0-2/fix-pkg-config/ I'm not sure why this patch was applied (I don't see a similar patch applied in UHD master in upstream). Could it be that libboost-system doesn't exist on some system architectures but it was unconditionally dropped with that patch? [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=939974 [2] https://osmocom.org/issues/4182 [3] https://build.opensuse.org/package/show/network:osmocom:nightly/osmo-trx [4] https://build.opensuse.org/package/live_build_log/network:osmocom:nightly/osmo-trx/Debian_Testing/x86_64 -- System Information: Debian Release: testing or unstable (works on buster stable) Architecture: amd64 (x86_64)
