This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/gerrit-log@lists.osmocom.org/.
Neels Hofmeyr gerrit-no-reply at lists.osmocom.orgNeels Hofmeyr has posted comments on this change. ( https://gerrit.osmocom.org/5844 ) Change subject: tests: fix LDADD: link libosmovty from current build ...................................................................... Patch Set 4: > $ make check V=s 2>&1 | grep libosmovty > > I see the following lines only: > > /bin/bash ../libtool --tag=CC --mode=link gcc -Wall -g -O2 > -DBUILDING_LIBOSMOCORE -Wall -o vty/vty_test vty/vty_test.o > ../src/libosmocore.la -ltalloc ../src/vty/libosmovty.la Exactly, only vty_test so far linked libosmovty directly from the build tree. The others apparently implicitly link it from where ever they can find it, in my case from /usr/local/lib? In an effort to understand wth is going on with linking, I reproduced this issue now: Build and install libosmocore from the tip of branch neels/logging. This makes logging_vty.c use loglevel_strs[], assert_loginfo(), tall_log_ctx from logging.c, and adds loglevel_descriptions[] to logging.c and calls that from logging_vty.c, too. So that means now logging_vty.c depends on these symbols to be public in libosmocore.a, where they were static before. With this state of linking installed, everything works fine. Now go back to libosmocore master, where these symbols are still static. Mind you, /usr/local/lib already has a libosmovty.a that depends on these symbols to be public in libosmocore. When I try to build now, I get CCLD ctrl/ctrl_test /usr/bin/ld: /usr/local/lib/libosmovty.so.4: undefined reference to `loglevel_strs' /usr/bin/ld: /usr/local/lib/libosmovty.so.4: undefined reference to `assert_loginfo' /usr/bin/ld: /usr/local/lib/libosmovty.so.4: undefined reference to `log_level_description' /usr/bin/ld: /usr/local/lib/libosmovty.so.4: undefined reference to `tall_log_ctx' collect2: error: ld returned 1 exit status Let's see /bin/bash ../libtool --tag=CC --mode=link gcc -Wall -g -O2 -fsanitize=address -fsanitize=undefined -Werror -Wno-error=deprecated -Wno-error=deprecated-declarations -Wno-error=cpp -DBUILDING_LIBOSMOCORE -Wall -o ctrl/ctrl_test ctrl/ctrl_test.o ../src/libosmocore.la -ltalloc ../src/ctrl/libosmoctrl.la libtool: link: gcc -Wall -g -O2 -fsanitize=address -fsanitize=undefined -Werror -Wno-error=deprecated -Wno-error=deprecated-declarations -Wno-error=cpp -DBUILDING_LIBOSMOCORE -Wall -o ctrl/.libs/ctrl_test ctrl/ctrl_test.o ../src/.libs/libosmocore.so -ltalloc ../src/ctrl/.libs/libosmoctrl.so /usr/bin/ld: /usr/local/lib/libosmovty.so.4: undefined reference to `loglevel_strs' /usr/bin/ld: /usr/local/lib/libosmovty.so.4: undefined reference to `assert_loginfo' /usr/bin/ld: /usr/local/lib/libosmovty.so.4: undefined reference to `log_level_description' /usr/bin/ld: /usr/local/lib/libosmovty.so.4: undefined reference to `tall_log_ctx' collect2: error: ld returned 1 exit status Clearly, libosmovty is not listed as linked library. But for some reason, libtool still pulls in a libosmovty. That's because of libosmoctrl.so! ▶ ldd src/ctrl/.libs/libosmoctrl.so linux-vdso.so.1 (0x00007ffced03f000) libasan.so.5 => /usr/lib/x86_64-linux-gnu/libasan.so.5 (0x00007f26c291b000) libtalloc.so.2 => /usr/lib/x86_64-linux-gnu/libtalloc.so.2 (0x00007f26c2903000) libosmocore.so.11 => /usr/local/lib/libosmocore.so.11 (0x00007f26c26d4000) libosmogsm.so.10 => /usr/local/lib/libosmogsm.so.10 (0x00007f26c22bb000) libosmovty.so.4 => /usr/local/lib/libosmovty.so.4 (0x00007f26c2171000) libubsan.so.1 => /usr/lib/x86_64-linux-gnu/libubsan.so.1 (0x00007f26c1650000) [...] It does so from /usr/local/lib in my case. The solution is thus: any program built in libosmocore.git, here regression test binary, that links libosmoctrl, *must* also make sure to link libosmovty and libosmogsm from the source tree, or the build works only when we're lucky. -- To view, visit https://gerrit.osmocom.org/5844 To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: libosmocore Gerrit-Branch: master Gerrit-MessageType: comment Gerrit-Change-Id: Id084e6e6efd25cd62b1bd7a4fc7c5985c39130c6 Gerrit-Change-Number: 5844 Gerrit-PatchSet: 4 Gerrit-Owner: Neels Hofmeyr <nhofmeyr at sysmocom.de> Gerrit-Reviewer: Jenkins Builder (1000002) Gerrit-Reviewer: Max <msuraev at sysmocom.de> Gerrit-Reviewer: Neels Hofmeyr <nhofmeyr at sysmocom.de> Gerrit-Reviewer: Vadim Yanitskiy <axilirator at gmail.com> Gerrit-Comment-Date: Tue, 11 Sep 2018 20:46:11 +0000 Gerrit-HasComments: No Gerrit-HasLabels: No -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.osmocom.org/pipermail/gerrit-log/attachments/20180911/851f7388/attachment.htm>