Bug #4182

osmo-trx build failures on obs

Added by laforge about 2 months ago. Updated 13 days ago.

Target version:
Start date:
Due date:
% Done:


Spec Reference:



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 "" && ln -s
"../" "" )
[  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/ ../Transceiver52M/arch/x86/ ../GSM/
../CommonLibs/ -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/
/usr/lib/x86_64-linux-gnu/ -ltalloc /usr/lib/x86_64-linux-gnu/
/usr/lib/x86_64-linux-gnu/ -luhd
[  322s] /usr/bin/ld: ./device/uhd/.libs/libdevice.a(UHDDevice.o): undefined reference to symbol
[  322s] /usr/bin/ld: /usr/lib/x86_64-linux-gnu/ 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." 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." at Fri Aug 30 04:20:38 UTC 2019.
[  326s]


#1 Updated by laforge about 2 months ago

  • Description updated (diff)
  • Assignee set to pespin

this is happening for several days in a row, at least on Debian unstable and testing.

#2 Updated by pespin about 2 months 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.

#3 Updated by pespin about 1 month ago

UHD version in stable (building fine): ,
UHD version in testing/unstable (build failure): ,

I'm pretty sure it fails to build due to this debian patch:

Description says:

 Fixes bug found by lintian:
 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.

#4 Updated by pespin about 1 month ago

  • Status changed from New to Feedback

#5 Updated by laforge about 1 month ago

Hi Pau,

On Thu, Sep 12, 2019 at 03:49:08PM +0000, pespin [REDMINE] wrote:

Debian bug being tracked here:

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.

#7 Updated by laforge 16 days ago

  • Priority changed from Normal to High

#8 Updated by laforge 14 days 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:

#9 Updated by laforge 13 days ago

From: Michael Dickens <>
To: Harald Welte <>
Cc: GNURadio Discussion List <>, "A. Maitland Bottoms" <>, Pau
        Espin Pedrol <>
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
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

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)