Change in libosmocore[master]: tests: fix LDADD: link libosmovty from current build

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.org
Tue Sep 11 20:46:11 UTC 2018


Neels 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>


More information about the gerrit-log mailing list