Bug #4182
closedosmo-trx build failures on obs
100%
Description
Package network:osmocom:nightly/osmo-trx failed to build in Debian_Unstable/x86_64
Check out the package for editing:
osc checkout network:osmocom:nightly osmo-trx
Last lines of build log:
[ 322s] ar: `u' modifier ignored since `D' is the default (see `U') [ 322s] libtool: link: ranlib .libs/libtransceiver_common.a [ 322s] libtool: link: ( cd ".libs" && rm -f "libtransceiver_common.la" && ln -s "../libtransceiver_common.la" "libtransceiver_common.la" ) [ 322s] /bin/bash ../libtool --tag=CXX --mode=link g++ -lpthread -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,relro -Wl,-z,now -o osmo-trx-uhd osmo_trx_uhd-osmo-trx.o ./device/uhd/libdevice.la libtransceiver_common.la ../Transceiver52M/arch/x86/libarch.la ../GSM/libGSM.la ../CommonLibs/libcommon.la -lfftw3f -ltalloc -losmocore -ltalloc -losmoctrl -losmogsm -losmocore -ltalloc -losmovty -losmocore -luhd [ 322s] 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 [ 322s] /usr/bin/ld: ./device/uhd/.libs/libdevice.a(UHDDevice.o): undefined reference to symbol '_ZN5boost6system16generic_categoryEv' [ 322s] /usr/bin/ld: /usr/lib/x86_64-linux-gnu/libboost_system.so.1.67.0: error adding symbols: DSO missing from command line [ 322s] collect2: error: ld returned 1 exit status [ 322s] make[4]: *** [Makefile:681: osmo-trx-uhd] Error 1 [ 322s] make[4]: Leaving directory '/usr/src/packages/BUILD/Transceiver52M' [ 322s] make[3]: *** [Makefile:820: all-recursive] Error 1 [ 322s] make[3]: Leaving directory '/usr/src/packages/BUILD/Transceiver52M' [ 322s] make[2]: *** [Makefile:513: all-recursive] Error 1 [ 322s] make[2]: Leaving directory '/usr/src/packages/BUILD' [ 322s] make[1]: *** [Makefile:444: all] Error 2 [ 322s] make[1]: Leaving directory '/usr/src/packages/BUILD' [ 322s] dh_auto_build: make -j1 returned exit code 2 [ 322s] make: *** [debian/rules:6: build] Error 255 [ 322s] dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2 [ 323s] [ 323s] sheep81 failed "build osmo-trx_1.1.1.10.77f3.dsc" at Fri Aug 30 04:20:34 UTC 2019. [ 323s] [ 323s] ### VM INTERACTION START ### [ 326s] [ 312.108425] sysrq: SysRq : Power Off [ 326s] [ 312.113858] reboot: Power down [ 326s] ### VM INTERACTION END ### [ 326s] [ 326s] sheep81 failed "build osmo-trx_1.1.1.10.77f3.dsc" at Fri Aug 30 04:20:38 UTC 2019. [ 326s]
Updated by laforge over 4 years ago
- Description updated (diff)
- Assignee set to pespin
this is happening for several days in a row, at least on Debian unstable and testing.
Updated by pespin over 4 years ago
- Category set to UHD
I already did some comments on it on IRC a few days ago.
To me it looks like a bug in UHD pkgconfig not providing -lboost_system in some architectures, or a bug in boost_system itself.
Updated by pespin over 4 years ago
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
I'm pretty sure it fails to build due to this debian patch:
https://sources.debian.org/patches/uhd/3.14.1.0-2/fix-pkg-config/
Description says:
fix-pkg-config Fixes bug found by lintian: pkg-config-references-unknown-shared-library pkgconfig/uhd.pc -lboost_system (line 14)
So I think on some systems liboost_system may exist, and it doesn't exist on others. (And thus the patch is wrong unconditionally removing it).
That patch is only applied to the failing versions, not the older working version.
Updated by pespin over 4 years ago
- Status changed from New to Feedback
Debian bug being tracked here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=939974
Updated by laforge over 4 years ago
Hi Pau,
On Thu, Sep 12, 2019 at 03:49:08PM +0000, pespin [REDMINE] wrote:
Debian bug being tracked here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=939974
this is the "wrong" bug report. As I indicated twice on IRC today, the
bug must be reported against the package that actually causes the bug.
You have identified that as the uhd package. I doubt the uhd package
maintainer will look at osmo-trx bugs.
Updated by pespin over 4 years ago
UHD bug reported here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=940135
Updated by laforge over 4 years ago
- % Done changed from 0 to 10
Normally, one would expect that uhd pkg-config "Requires" libboost-system. However, boost cannot be bothered to provide pkgconfig files, see this 12 year old feature request: https://svn.boost.org/trac10/ticket/1094
Updated by laforge over 4 years ago
From: Michael Dickens <michael.dickens@ettus.com> To: Harald Welte <laforge@osmocom.org> Cc: GNURadio Discussion List <discuss-gnuradio@gnu.org>, "A. Maitland Bottoms" <bottoms@debian.org>, Pau Espin Pedrol <pespin@sysmocom.de> Subject: Re: [Discuss-gnuradio] UHD / -lboost_system / pkg-config / Debian patch Hi Harald - Mait & I talked about this issue during GRCon19 a few weeks ago. I believe we came to the same conclusions as you note: A project that does not otherwise require non-UHD library/ies should not have to know to link against them (nor how). The linkage should be provided transparently by CMake or pkgconfig or whatever: variables are returned from "find"ing UHD that provides CFLAGS, CXXFLAGS, LDFLAGS, LIBRARIES, LIBRARY_DIRS, INCLUDE_DIRS, and so forth. These variables can then be used as-is by the calling project without having to know anything else about how the API or ABI is built, installed, or used beyond these variables. The correct way to do this varies depending on which "find" is used. For pkgconfig, using "Requires.private" or "Requires" or just leaving the linkage as before the patch ... any of those might work. But, yes, the bottom line is that the patch you note isn't doing the right thing and needs to be either fixed or removed. I'm leaving it to Mait to deal with this as he sees fit; I think we'd all prefer this get done sooner rather than later. - MLD
Updated by pespin over 4 years ago
- Status changed from Feedback to Resolved
- % Done changed from 10 to 100
From what I read in debian bug reports it seems the build issue is fixed, so I'm closing the ticket. osmo-trx is not currently building for those distros due to different issue inherited from osmo-gsm-manuals, see #4246.