Actions
Bug #3517
closedosmo-trx nightly builds link against the wrong libosmovty version
Start date:
09/04/2018
Due date:
% Done:
100%
Spec Reference:
Description
it seems todays nightly packages for osmo-trx-uhd osmo-trx-usrp1 and osmo-ggsn (!) but not osmo-trx-lms link against libosmovty.so.0 also
root@test123:~/src/osmo-trx# ldd /usr/bin/osmo-trx-lms
linux-vdso.so.1 (0x00007fff5e36a000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f2257965000)
libfftw3f.so.3 => /usr/lib/x86_64-linux-gnu/libfftw3f.so.3 (0x00007f2257557000)
libosmoctrl.so.0 => /usr/lib/x86_64-linux-gnu/libosmoctrl.so.0 (0x00007f225734d000)
libosmogsm.so.10 => /usr/lib/x86_64-linux-gnu/libosmogsm.so.10 (0x00007f22570f4000)
libtalloc.so.2 => /usr/lib/x86_64-linux-gnu/libtalloc.so.2 (0x00007f2256ee0000)
libosmovty.so.4 => /usr/lib/x86_64-linux-gnu/libosmovty.so.4 (0x00007f2256cc0000)
libosmocore.so.11 => /usr/lib/x86_64-linux-gnu/libosmocore.so.11 (0x00007f2256a98000)
libLimeSuite.so.18.06-1 => /usr/lib/x86_64-linux-gnu/libLimeSuite.so.18.06-1 (0x00007f22567da000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f2256458000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f2256154000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f2255f3d000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f2255b9e000)
/lib64/ld-linux-x86-64.so.2 (0x00007f2257dc9000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f225599a000)
libgnutls.so.30 => /usr/lib/x86_64-linux-gnu/libgnutls.so.30 (0x00007f2255601000)
libusb-1.0.so.0 => /lib/x86_64-linux-gnu/libusb-1.0.so.0 (0x00007f22553e8000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f22551ce000)
libp11-kit.so.0 => /usr/lib/x86_64-linux-gnu/libp11-kit.so.0 (0x00007f2254f69000)
libidn.so.11 => /lib/x86_64-linux-gnu/libidn.so.11 (0x00007f2254d35000)
libtasn1.so.6 => /usr/lib/x86_64-linux-gnu/libtasn1.so.6 (0x00007f2254b22000)
libnettle.so.6 => /usr/lib/x86_64-linux-gnu/libnettle.so.6 (0x00007f22548eb000)
libhogweed.so.4 => /usr/lib/x86_64-linux-gnu/libhogweed.so.4 (0x00007f22546b6000)
libgmp.so.10 => /usr/lib/x86_64-linux-gnu/libgmp.so.10 (0x00007f2254433000)
libudev.so.1 => /lib/x86_64-linux-gnu/libudev.so.1 (0x00007f2257fb5000)
libffi.so.6 => /usr/lib/x86_64-linux-gnu/libffi.so.6 (0x00007f225422a000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f2254022000)
root@test123:~/src/osmo-trx# ldd /usr/bin/osmo-trx-uhd
linux-vdso.so.1 (0x00007fffec3f0000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fb68f06b000)
libfftw3f.so.3 => /usr/lib/x86_64-linux-gnu/libfftw3f.so.3 (0x00007fb68ec5d000)
libosmoctrl.so.0 => /usr/lib/x86_64-linux-gnu/libosmoctrl.so.0 (0x00007fb68ea53000)
libosmogsm.so.10 => /usr/lib/x86_64-linux-gnu/libosmogsm.so.10 (0x00007fb68e7fa000)
libtalloc.so.2 => /usr/lib/x86_64-linux-gnu/libtalloc.so.2 (0x00007fb68e5e6000)
libosmovty.so.0 => not found
libosmocore.so.11 => /usr/lib/x86_64-linux-gnu/libosmocore.so.11 (0x00007fb68e3be000)
libuhd.so.003 => /usr/lib/x86_64-linux-gnu/libuhd.so.003 (0x00007fb68da9a000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fb68d718000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fb68d414000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fb68d1fd000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fb68ce5e000)
/lib64/ld-linux-x86-64.so.2 (0x00007fb68f4d7000)
libosmovty.so.4 => /usr/lib/x86_64-linux-gnu/libosmovty.so.4 (0x00007fb68cc3e000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fb68ca3a000)
libgnutls.so.30 => /usr/lib/x86_64-linux-gnu/libgnutls.so.30 (0x00007fb68c6a1000)
libboost_date_time.so.1.62.0 => /usr/lib/x86_64-linux-gnu/libboost_date_time.so.1.62.0 (0x00007fb68c490000)
libboost_filesystem.so.1.62.0 => /usr/lib/x86_64-linux-gnu/libboost_filesystem.so.1.62.0 (0x00007fb68c277000)
libboost_program_options.so.1.62.0 => /usr/lib/x86_64-linux-gnu/libboost_program_options.so.1.62.0 (0x00007fb68bff8000)
libboost_regex.so.1.62.0 => /usr/lib/x86_64-linux-gnu/libboost_regex.so.1.62.0 (0x00007fb68bcdf000)
libboost_system.so.1.62.0 => /usr/lib/x86_64-linux-gnu/libboost_system.so.1.62.0 (0x00007fb68badb000)
libboost_unit_test_framework.so.1.62.0 => /usr/lib/x86_64-linux-gnu/libboost_unit_test_framework.so.1.62.0 (0x00007fb68b816000)
libboost_serialization.so.1.62.0 => /usr/lib/x86_64-linux-gnu/libboost_serialization.so.1.62.0 (0x00007fb68b5d5000)
libboost_thread.so.1.62.0 => /usr/lib/x86_64-linux-gnu/libboost_thread.so.1.62.0 (0x00007fb68b3ad000)
libboost_chrono.so.1.62.0 => /usr/lib/x86_64-linux-gnu/libboost_chrono.so.1.62.0 (0x00007fb68b1a6000)
libboost_atomic.so.1.62.0 => /usr/lib/x86_64-linux-gnu/libboost_atomic.so.1.62.0 (0x00007fb68afa4000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fb68ad9c000)
libusb-1.0.so.0 => /lib/x86_64-linux-gnu/libusb-1.0.so.0 (0x00007fb68ab83000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fb68a969000)
libp11-kit.so.0 => /usr/lib/x86_64-linux-gnu/libp11-kit.so.0 (0x00007fb68a704000)
libidn.so.11 => /lib/x86_64-linux-gnu/libidn.so.11 (0x00007fb68a4d0000)
libtasn1.so.6 => /usr/lib/x86_64-linux-gnu/libtasn1.so.6 (0x00007fb68a2bd000)
libnettle.so.6 => /usr/lib/x86_64-linux-gnu/libnettle.so.6 (0x00007fb68a086000)
libhogweed.so.4 => /usr/lib/x86_64-linux-gnu/libhogweed.so.4 (0x00007fb689e51000)
libgmp.so.10 => /usr/lib/x86_64-linux-gnu/libgmp.so.10 (0x00007fb689bce000)
libicudata.so.57 => /usr/lib/x86_64-linux-gnu/libicudata.so.57 (0x00007fb688151000)
libicui18n.so.57 => /usr/lib/x86_64-linux-gnu/libicui18n.so.57 (0x00007fb687cd7000)
libicuuc.so.57 => /usr/lib/x86_64-linux-gnu/libicuuc.so.57 (0x00007fb68792f000)
libboost_timer.so.1.62.0 => /usr/lib/x86_64-linux-gnu/libboost_timer.so.1.62.0 (0x00007fb68772a000)
libudev.so.1 => /lib/x86_64-linux-gnu/libudev.so.1 (0x00007fb68f6bf000)
libffi.so.6 => /usr/lib/x86_64-linux-gnu/libffi.so.6 (0x00007fb687521000)
Updated by laforge over 5 years ago
- Status changed from New to In Progress
I created a debian9 LXC and installed nothing but the osmocom packages and their dependencies.
I get
root@20180904-packages:/root# ldd /usr/bin/osmo-trx-uhd | grep vty
libosmovty.so.0 => not found
libosmovty.so.4 => /usr/lib/x86_64-linux-gnu/libosmovty.so.4 (0x00007f2eb37cc000)
root@20180904-packages:/root# ldd /usr/bin/osmo-trx-usrp1 | grep vty
libosmovty.so.0 => not found
libosmovty.so.4 => /usr/lib/x86_64-linux-gnu/libosmovty.so.4 (0x00007f26f1f01000)
root@20180904-packages:/root# ldd /usr/bin/osmo-trx-lms | grep vty
libosmovty.so.4 => /usr/lib/x86_64-linux-gnu/libosmovty.so.4 (0x00007f122c5ae000)
So osmo-trx-lms is correct, while -uhd and -usrp1 are broken.
Also, the dependency is created by the program itself, and not indirectly by another library as
root@20180904-packages:/root# ldd /usr/lib/x86_64-linux-gnu/libosmo* 2>&1 | grep libosmovty.so.0
gives an empty result.
Updated by laforge over 5 years ago
This is rather weird, as I cannot see any difference in the way how we link the three:
if DEVICE_UHD bin_PROGRAMS += osmo-trx-uhd osmo_trx_uhd_SOURCES = osmo-trx.cpp osmo_trx_uhd_LDADD = \ »·······$(builddir)/device/uhd/libdevice.la \ »·······$(COMMON_LDADD) \ »·······$(UHD_LIBS) osmo_trx_uhd_CPPFLAGS = $(AM_CPPFLAGS) $(UHD_CFLAGS) endif if DEVICE_USRP1 bin_PROGRAMS += osmo-trx-usrp1 osmo_trx_usrp1_SOURCES = osmo-trx.cpp osmo_trx_usrp1_LDADD = \ »·······$(builddir)/device/usrp1/libdevice.la \ »·······$(COMMON_LDADD) \ »·······$(USRP_LIBS) osmo_trx_usrp1_CPPFLAGS = $(AM_CPPFLAGS) $(USRP_CFLAGS) endif if DEVICE_LMS bin_PROGRAMS += osmo-trx-lms osmo_trx_lms_SOURCES = osmo-trx.cpp osmo_trx_lms_LDADD = \ »·······$(builddir)/device/lms/libdevice.la \ »·······$(COMMON_LDADD) \ »·······$(LMS_LIBS) osmo_trx_lms_CPPFLAGS = $(AM_CPPFLAGS) $(LMS_CFLAGS) endif
as well as
--- Transceiver52M/device/lms/Makefile.am 2018-07-31 15:47:44.920199108 +0200
+++ Transceiver52M/device/uhd/Makefile.am 2018-04-28 21:43:26.621429964 +0200
@@ -1,10 +1,8 @@
include $(top_srcdir)/Makefile.common
AM_CPPFLAGS = -Wall $(STD_DEFINES_AND_INCLUDES) -I${srcdir}/..
-AM_CXXFLAGS = -lpthread $(LIBOSMOCORE_CFLAGS) $(LIBOSMOCTRL_CFLAGS) $(LIBOSMOVTY_CFLAGS) $(LMS_CFLAGS)
-
-noinst_HEADERS = LMSDevice.h
+AM_CXXFLAGS = -lpthread $(LIBOSMOCORE_CFLAGS) $(LIBOSMOCTRL_CFLAGS) $(LIBOSMOVTY_CFLAGS) $(UHD_CFLAGS)
noinst_LTLIBRARIES = libdevice.la
-libdevice_la_SOURCES = LMSDevice.cpp
+libdevice_la_SOURCES = UHDDevice.cpp
so there's not really any difference in how they are linked...
Updated by laforge over 5 years ago
The odd part is the version numbers of the packages:
Get:1 http://download.opensuse.org/repositories/network:/osmocom:/nightly/Debian_9.0 ./ osmo-trx-uhd 0.4.0 [119 kB] Get:2 http://download.opensuse.org/repositories/network:/osmocom:/nightly/Debian_9.0 ./ osmo-trx 0.4.0 [8306 B] Get:3 http://download.opensuse.org/repositories/network:/osmocom:/nightly/Debian_9.0 ./ osmo-trx-lms 0.4.0 [104 kB]
Updated by laforge over 5 years ago
- Assignee set to laforge
normally I'd expect something like a git commit extended version number:
ii libosmocore11:amd64 0.12.0.41.b99e amd64 Osmo Core library ii libosmoctrl0:amd64 0.12.0.41.b99e amd64 Osmo control library ii libosmogsm10:amd64 0.12.0.41.b99e amd64 Osmo GSM utility library ii libosmovty4:amd64 0.12.0.41.b99e amd64 Osmo VTY library ii osmo-ggsn 1.2.2.9.ee44 amd64 Osmocom Gateway GPRS Support Node (GGSN)
Updated by laforge over 5 years ago
- Assignee changed from laforge to pespin
- % Done changed from 0 to 30
the wrong version number seemed to be a result of a broken git-version-gen script. See https://gerrit.osmocom.org/#/c/osmo-trx/+/10759
Updated by laforge over 5 years ago
- Status changed from In Progress to Resolved
- Assignee changed from pespin to laforge
- % Done changed from 30 to 100
After my patch to fix git-version-gen, the package version has been correct for several consecutive nightly builds.
I've started with a Debian container from one week ago and then subsequently updated the nightly feed every night. The package update always automatically installed the new packages and none of them showed the weird library dependency anymore.
I cannot really say exactly why the package version would have any influence on this, but it looks like it. Maybe OBS or some reverse proxy simply delivered a cahced older package as the filename didn't change from night to night - despite the actual source code changing?
Anyway, marking as resolved as the problem doesn't appear anymore.
Actions
