Bug #4936
closed
osmo-pcu OBS nightly builds all fail "/usr/bin/ld: cannot find -lmnl"
Added by laforge over 3 years ago.
Updated over 3 years ago.
Description
Tonight, all our osmo-pcu (and osmo-sgsn) builds started to fail with:
[ 308s] CXX pcu_main.o
[ 308s] CXX gprs_debug.lo
[ 308s] CC csn1.lo
[ 308s] CC gsm_rlcmac.lo
[ 308s] CXX gprs_bssgp_pcu.lo
[ 308s] CXX gprs_rlcmac.lo
[ 308s] CXX gprs_rlcmac_sched.lo
[ 308s] CXX gprs_rlcmac_meas.lo
[ 310s] CXX gprs_rlcmac_ts_alloc.lo
[ 312s] CC gprs_ms.lo
[ 312s] CXX gprs_ms_storage.lo
[ 312s] CXX gsm_timer.lo
[ 313s] CXX pcu_l1_if.lo
[ 313s] CC pcu_vty.lo
[ 314s] CXX pcu_vty_functions.lo
[ 315s] CC mslot_class.lo
[ 315s] CXX tbf.lo
[ 316s] CXX tbf_ul.lo
[ 316s] CXX tbf_dl.lo
[ 316s] CXX bts.lo
[ 317s] CXX pdch.lo
[ 318s] CXX poll_controller.lo
[ 318s] CXX encoding.lo
[ 318s] CXX sba.lo
[ 321s] CXX decoding.lo
[ 322s] CXX llc.lo
[ 322s] CXX rlc.lo
[ 322s] CXX osmobts_sock.lo
[ 323s] CC gprs_codel.lo
[ 323s] CC coding_scheme.lo
[ 324s] CXX egprs_rlc_compression.lo
[ 327s] CXXLD libgprs.la
[ 327s] copying selected object files to avoid basename conflicts...
[ 327s] CXXLD osmo-pcu
[ 328s] /usr/bin/ld: cannot find -lmnl
[ 328s] collect2: error: ld returned 1 exit status
[ 328s] make[1]: *** [Makefile:723: osmo-pcu] Error 1
I don't really get why this is happening. libosmocore.so.* is linked with libmnl.so.x.y.z, so there is absolutely no need to link each application explicitly against "-lmnl". The latter would require libmnl-dev to be installed, which it is not (and which it should not required to be).
So where does the sudden "-lmnl" come from?
even the Centos8 RPM builds are affected, so it's also not soemthing that debian might have changed...
This is the output from a "V=1" build:
[ 314s] copying selected object files to avoid basename conflicts...
[ 314s] libtool: link: ln .libs/gprs_rlcmac_sched.o .libs/libgprs.lax/lt1-gprs_rlcmac_sched.o || cp .libs/gprs_rlcmac_sched.o .libs/libgprs.lax/lt1-gprs_rlcmac_sched.o
[ 314s] libtool: link: ar cru .libs/libgprs.a .libs/gprs_debug.o .libs/csn1.o .libs/gsm_rlcmac.o .libs/gprs_bssgp_pcu.o .libs/gprs_rlcmac.o .libs/gprs_rlcmac_sched.o .libs/gprs_rlcmac_meas.o .libs/gprs_rlcmac_ts_alloc.o .libs/gprs_ms.o .libs/gprs_ms_storage.o .libs/gsm_timer.o .libs/pcu_l1_if.o .libs/pcu_vty.o .libs/pcu_vty_functions.o .libs/mslot_class.o .libs/tbf.o .libs/tbf_ul.o .libs/tbf_dl.o .libs/bts.o .libs/pdch.o .libs/poll_controller.o .libs/encoding.o .libs/sba.o .libs/decoding.o .libs/llc.o .libs/rlc.o .libs/osmobts_sock.o .libs/gprs_codel.o .libs/coding_scheme.o .libs/egprs_rlc_compression.o .libs/libgprs.lax/lt1-gprs_rlcmac_sched.o
[ 314s] ar: `u' modifier ignored since `D' is the default (see `U')
[ 314s] libtool: link: ranlib .libs/libgprs.a
[ 314s] libtool: link: rm -fr .libs/libgprs.lax
[ 314s] libtool: link: ( cd ".libs" && rm -f "libgprs.la" && ln -s "../libgprs.la" "libgprs.la" )
[ 314s] /bin/bash ../libtool --tag=CXX --mode=link g++ -Wall -ldl -pthread -g -O2 -fdebug-prefix-map=/usr/src/packages/BUILD=. -fstack-protector-strong -Wformat -Werror=format-security -std=gnu++03 -lrt -Wl,-z,relro -Wl,-z,now -o osmo-pcu pcu_main.o libgprs.la -ltalloc -losmogb -losmovty -losmocore -lmnl -ltalloc -losmocore -ltalloc -losmogsm -losmocore
[ 315s] libtool: link: g++ -Wall -pthread -g -O2 -fdebug-prefix-map=/usr/src/packages/BUILD=. -fstack-protector-strong -Wformat -Werror=format-security -std=gnu++03 -Wl,-z -Wl,relro -Wl,-z -Wl,now -o osmo-pcu pcu_main.o ./.libs/libgprs.a -ldl -lrt /usr/lib/x86_64-linux-gnu/libosmogb.so /usr/lib/x86_64-linux-gnu/libosmovty.so -lmnl -ltalloc /usr/lib/x86_64-linux-gnu/libosmogsm.so /usr/lib/x86_64-linux-gnu/libosmocore.so -pthread
[ 315s] /usr/bin/ld: cannot find -lmnl
[ 315s] collect2: error: ld returned 1 exit status
I don't see us including the -lmnl in our .pc files, where does it come from?
laforge wrote:
I don't see us including the -lmnl in our .pc files, where does it come from?
It's in libosmogb.pc:
libosmogb.pc:Libs: -L${libdir} -ltalloc -losmogb -losmovty -losmocore -lmnl
Either we don't have "-lmnl" in the .pc file (I would assume the shlib-dependency is sufficient (see ldd output):
root@debian9:/usr/lib/x86_64-linux-gnu/pkgconfig# ldd /usr/lib/x86_64-linux-gnu/libosmogb.so.9.1.0
linux-vdso.so.1 (0x00007ffe8b6fd000)
libtalloc.so.2 => /usr/lib/x86_64-linux-gnu/libtalloc.so.2 (0x00007fe8f6849000)
libosmocore.so.12 => /usr/lib/x86_64-linux-gnu/libosmocore.so.12 (0x00007fe8f6619000)
libosmovty.so.4 => /usr/lib/x86_64-linux-gnu/libosmovty.so.4 (0x00007fe8f63f0000)
libosmogsm.so.13 => /usr/lib/x86_64-linux-gnu/libosmogsm.so.13 (0x00007fe8f617a000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fe8f5f5d000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fe8f5bbe000)
/lib64/ld-linux-x86-64.so.2 (0x00007fe8f6c7c000)
libsctp.so.1 => /usr/lib/x86_64-linux-gnu/libsctp.so.1 (0x00007fe8f59bb000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fe8f57b7000)
libosmocore.so.16 => /usr/lib/x86_64-linux-gnu/libosmocore.so.16 (0x00007fe8f5583000)
libgnutls.so.30 => /usr/lib/x86_64-linux-gnu/libgnutls.so.30 (0x00007fe8f51ea000)
libmnl.so.0 => /lib/x86_64-linux-gnu/libmnl.so.0 (0x00007fe8f4fe3000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fe8f4dc9000)
libp11-kit.so.0 => /usr/lib/x86_64-linux-gnu/libp11-kit.so.0 (0x00007fe8f4b64000)
libidn.so.11 => /lib/x86_64-linux-gnu/libidn.so.11 (0x00007fe8f4930000)
libtasn1.so.6 => /usr/lib/x86_64-linux-gnu/libtasn1.so.6 (0x00007fe8f471d000)
libnettle.so.6 => /usr/lib/x86_64-linux-gnu/libnettle.so.6 (0x00007fe8f44e6000)
libhogweed.so.4 => /usr/lib/x86_64-linux-gnu/libhogweed.so.4 (0x00007fe8f42b1000)
libgmp.so.10 => /usr/lib/x86_64-linux-gnu/libgmp.so.10 (0x00007fe8f402e000)
libffi.so.6 => /usr/lib/x86_64-linux-gnu/libffi.so.6 (0x00007fe8f3e25000)
or we add "-lmnl" to the LDFLAGS for every application, but then we'd also need to have make libosmocore-dev depend on libmnl-dev to ensure the libmnl.so file is actually present.
- Assignee changed from pespin to Hoernchen
mh, I just saw the following commit:
commit 2253224b33ae9f54f14dc54f0098c4d5ee27fdbf
Author: Eric <ewild@sysmocom.de>
Date: Thu Jan 7 14:56:10 2021 +0100
pkgconfig: link to mnl if available
The dependency on mnl breaks builds of osmo-pcu et al if mnl is used for
libosmogb, but not linked in for lib users
Change-Id: Ib4df95d5c922f8edfa33e68645652fd30d321ff8
diff --git a/libosmogb.pc.in b/libosmogb.pc.in
index a163cc42..4eebe428 100644
--- a/libosmogb.pc.in
+++ b/libosmogb.pc.in
@@ -6,6 +6,6 @@ includedir=@includedir@
Name: Osmocom GPRS Gb Library
Description: Osmocom GPRS Gb Interface (NS/BSSGP) Library
Version: @VERSION@
-Libs: -L${libdir} @TALLOC_LIBS@ -losmogb -losmovty -losmocore
+Libs: -L${libdir} @TALLOC_LIBS@ -losmogb -losmovty -losmocore @LIBMNL_LIBS@
Cflags: -I${includedir}/ -fno-strict-aliasing
I believe the commit to be wrong, for reasons stated above. Why is it not sufficient that libosmocore.so.x.y.z has a dependency to libmnl.so.0 as stated in the above LDD output?
And if we really need to add that "-lmnl" to the Libs, then
- I think it should be done via "Requires:" of pkg-config
- We must do the same for all other shared library dependencies we have (see ldd output)
- We must make sure that libosmocore-dev depends on virtually all other lib*-dev packages that we list in BuildRequires
I just tested it on a Debian 9 system:
- remove libmnl-dev
- build fails like on OBS
- remove the "-lmnl" from the libosmogb.pc
- build completes fine as it always did
From https://people.freedesktop.org/~dbn/pkg-config-guide.html
Requires and Requires.private define other modules needed by the library. It is usually preferred to use the private variant of Requires to avoid exposing unnecessary libraries to the program that is linking with your library. If the program will not be using the symbols of the required library, it should not be linking directly to that library. See the discussion of "overlinking": for a more thorough explanation.
So unless we have some inline functions inside the libosmogb header files which make the application use symbols of libmnl directly (which I'm sure we don't), ther eshould not be any linking of the application.
For talloc it is different, as we do have quite a number of inline functions that directly use talloc_* symbols and hence the application will end up having to link it directly (we should still do it via Requires and not via Libs, and IIRC this was discussed before, but the concecus was not to change a working system).
- % Done changed from 0 to 100
Reverting this was fine, the actual issue is that it works with ld, but not with clang+lld, which was accidentally left enabled as linker in my build scripts - I don't know why that broke it, but I don't really care at the moment, I've spent considerable time debugging perf at one point because lld defaults to FNV1 hash instead of SHA1 for the build id and the perf build id cache broke due to that because the hash size differs, so there might very well be other weird differencences.
- Status changed from New to Resolved
Also available in: Atom
PDF
