Project

General

Profile

Bug #4182

osmo-trx build failures on obs

Added by laforge 3 months ago. Updated about 2 months ago.

Status:
Feedback
Priority:
High
Assignee:
Category:
UHD
Target version:
-
Start date:
08/30/2019
Due date:
% Done:

10%

Spec Reference:

Description

Visit
https://build.opensuse.org/package/live_build_log/network:osmocom:nightly/osmo-trx/Debian_Unstable/x86_64

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]

History

#1 Updated by laforge 3 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 3 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 2 months 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.

#4 Updated by pespin 2 months ago

  • Status changed from New to Feedback

#5 Updated by laforge 2 months 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.

#7 Updated by laforge about 2 months ago

  • Priority changed from Normal to High

#8 Updated by laforge about 2 months 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

#9 Updated by laforge about 2 months 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

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)