Bug #4936

osmo-pcu OBS nightly builds all fail "/usr/bin/ld: cannot find -lmnl"

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

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


Spec Reference:


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
[  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.* is linked with, 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?

Associated revisions

Revision 5d797c42 (diff)
Added by laforge 3 months ago

Revert "pkgconfig: link to mnl if available"

This reverts commit 2253224b33ae9f54f14dc54f0098c4d5ee27fdbf.

Reason for revert: Causes massive build failure for osmo-pcu and osmo-sgsn on all the distributions/architectures we build for

Change-Id: I6dbe4507701bee013b29dcc26f32c4e1a3c23613
Closes: OS#4936


#1 Updated by laforge 3 months ago

even the Centos8 RPM builds are affected, so it's also not soemthing that debian might have changed...

#2 Updated by laforge 3 months ago

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 "" && ln -s "../" "" )
[  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 -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/ /usr/lib/x86_64-linux-gnu/ -lmnl -ltalloc /usr/lib/x86_64-linux-gnu/ /usr/lib/x86_64-linux-gnu/ -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?

#3 Updated by laforge 3 months ago

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/ (0x00007ffe8b6fd000) => /usr/lib/x86_64-linux-gnu/ (0x00007fe8f6849000) => /usr/lib/x86_64-linux-gnu/ (0x00007fe8f6619000) => /usr/lib/x86_64-linux-gnu/ (0x00007fe8f63f0000) => /usr/lib/x86_64-linux-gnu/ (0x00007fe8f617a000) => /lib/x86_64-linux-gnu/ (0x00007fe8f5f5d000) => /lib/x86_64-linux-gnu/ (0x00007fe8f5bbe000)
        /lib64/ (0x00007fe8f6c7c000) => /usr/lib/x86_64-linux-gnu/ (0x00007fe8f59bb000) => /lib/x86_64-linux-gnu/ (0x00007fe8f57b7000) => /usr/lib/x86_64-linux-gnu/ (0x00007fe8f5583000) => /usr/lib/x86_64-linux-gnu/ (0x00007fe8f51ea000) => /lib/x86_64-linux-gnu/ (0x00007fe8f4fe3000) => /lib/x86_64-linux-gnu/ (0x00007fe8f4dc9000) => /usr/lib/x86_64-linux-gnu/ (0x00007fe8f4b64000) => /lib/x86_64-linux-gnu/ (0x00007fe8f4930000) => /usr/lib/x86_64-linux-gnu/ (0x00007fe8f471d000) => /usr/lib/x86_64-linux-gnu/ (0x00007fe8f44e6000) => /usr/lib/x86_64-linux-gnu/ (0x00007fe8f42b1000) => /usr/lib/x86_64-linux-gnu/ (0x00007fe8f402e000) => /usr/lib/x86_64-linux-gnu/ (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 file is actually present.

#4 Updated by laforge 3 months ago

  • Assignee changed from pespin to Hoernchen

mh, I just saw the following commit:

commit 2253224b33ae9f54f14dc54f0098c4d5ee27fdbf
Author: Eric <>
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/ b/
index a163cc42..4eebe428 100644
--- a/
+++ b/
@@ -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 has a dependency to 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

#5 Updated by laforge 3 months ago

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

#7 Updated by laforge 3 months ago


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).

#8 Updated by Hoernchen 3 months ago

  • % 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.

#9 Updated by laforge 3 months ago

  • Status changed from New to Resolved

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)