Hi all,
I am having an automake / libtool problem and don't know how to solve it.
In libosmo-pfcp, there is the pfcp_test binary, which obviously requires linking libosmo-pfcp.so -- more precisely, it should NOT link the system installed libosmo-pfcp.so, but the locally built one, libosmo-pfcp.a.
I try to accomplish this by:
pfcp_test_LDADD = \ $(LIBOSMOCORE_LIBS) \ $(top_builddir)/src/libosmo-pfcp/libosmo-pfcp.la \ $(top_builddir)/src/libosmo-gtlv/libosmo-gtlv.la \ $(NULL)
https://cgit.osmocom.org/libosmo-pfcp/tree/tests/libosmo-pfcp/Makefile.am
I am now adding a new optional IE to libosmo-pfcp, and I found that this does not work as expected! The pfcp_test binary is linked to the previously installed libosmo-pfcp.so in /usr/local/lib, instead of the proper, new version from the build tree. I found out by getting an obscure ABI corruption error, verified it by:
~/osmo-dev/make/libosmo-pfcp/tests/libosmo-pfcp $ ldd .libs/pfcp_test [...] libosmo-pfcp.so.0 => /usr/local/lib/libosmo-pfcp.so.0 (0x00007f1b6bc00000) libosmo-gtlv.so.0 => /usr/local/lib/libosmo-gtlv.so.0 (0x00007f1b6cc0a000) [...]
As soon as I 'make uninstall' in libosmo-pfcp.git's root dir, this changes to:
▶ ldd .libs/pfcp_test [...] libosmo-pfcp.so.0 => not found libosmo-gtlv.so.0 => not found [...]
and then the test succeeds (because './pfcp_test' is actually a shell script generated by libtool with linker magic referencing the libs built within the libosmo-pfcp.git tree).
Now I am at a loss:
How do I tell automake (libtool) to keep out the system installed .so and prioritize the libs in the build tree?
I can work around this for me by doing 'make uninstall' every time the libosmo-pfcp ABI changes, but I would much rather fix this, so that users rebuilding a newer version pulled from git don't run into this obscure problem.
I suspect that we may have a similar pitfall in many other osmo source trees, because the Makefile.am *looks* like it takes care of this problem, but actually doesn't.
Any ideas?
I am using:
automake (GNU automake) 1.16.5 autoconf (GNU Autoconf) 2.71 libtoolize (GNU libtool) 2.4.7 (Debian Unstable)
Thanks! ~N
Hi Neels,
On 11/21/22 07:00, Neels Hofmeyr wrote:
I am having an automake / libtool problem and don't know how to solve it.
In libosmo-pfcp, there is the pfcp_test binary, which obviously requires linking libosmo-pfcp.so -- more precisely, it should NOT link the system installed libosmo-pfcp.so, but the locally built one, libosmo-pfcp.a.
there's actually two binaries generated during the build process:
* tests/libosmo-pfcp/.libs/pfcp_test (generated by `make`) * tests/libosmo-pfcp/.libs/lt-pfcp_test (generated by `make check`)
The key difference between them is the RPATH:
* $(readelf --dynamic ./tests/libosmo-pfcp/.libs/pfcp_test) gives me: ** /usr/lib
* $(readelf --dynamic ./tests/libosmo-pfcp/.libs/lt-pfcp_test) gives me: ** /usr/lib ** /home/fixeria/projects/osmocom/libosmo-pfcp/src/libosmo-pfcp/.libs ** /home/fixeria/projects/osmocom/libosmo-pfcp/src/libosmo-gtlv/.libs
The '.libs/pfcp_test' is a binary that can be installed during `make install` (in this case it's not going to be installed because it's listed in 'noinst_PROGRAMS'), while the '.libs/lt-pfcp_test' is a binary that *should* be executed from the build tree during `make check`.
BTW, we should be using 'check_PROGRAMS', not 'noinst_PROGRAMS':
https://gerrit.osmocom.org/c/libosmo-pfcp/+/30250
I am now adding a new optional IE to libosmo-pfcp, and I found that this does not work as expected! The pfcp_test binary is linked to the previously installed libosmo-pfcp.so in /usr/local/lib, instead of the proper, new version from the build tree. I found out by getting an obscure ABI corruption error, verified it by:
~/osmo-dev/make/libosmo-pfcp/tests/libosmo-pfcp $ ldd .libs/pfcp_test [...] libosmo-pfcp.so.0 => /usr/local/lib/libosmo-pfcp.so.0 (0x00007f1b6bc00000) libosmo-gtlv.so.0 => /usr/local/lib/libosmo-gtlv.so.0 (0x00007f1b6cc0a000) [...]
As I explained above, it's expected that the ELF loader picks system-installed libraries for the '.libs/pfcp_test'. You need to examine the '.libs/lt-pfcp_test' instead.
As soon as I 'make uninstall' in libosmo-pfcp.git's root dir, this changes to:
▶ ldd .libs/pfcp_test [...] libosmo-pfcp.so.0 => not found libosmo-gtlv.so.0 => not found [...]
and then the test succeeds (because './pfcp_test' is actually a shell script generated by libtool with linker magic referencing the libs built within the libosmo-pfcp.git tree).
This is indeed weird. You should probably examine the libtool generated script. It should be executing the '.libs/lt-pfcp_test':
program=lt-'pfcp_test' progdir="$thisdir/.libs"
...
exec "$progdir/$program" ${1+"$@"}
I suspect that we may have a similar pitfall in many other osmo source trees, because the Makefile.am*looks* like it takes care of this problem, but actually doesn't.
AFAIR, you already brought a similar problem up back in 2018:
https://gerrit.osmocom.org/c/libosmocore/+/5844
Best regards, Vadim.
Hi Neels,
On 21.11.22 01:00, Neels Hofmeyr wrote:
I try to accomplish this by:
pfcp_test_LDADD = \ $(LIBOSMOCORE_LIBS) \ $(top_builddir)/src/libosmo-pfcp/libosmo-pfcp.la \ $(top_builddir)/src/libosmo-gtlv/libosmo-gtlv.la \ $(NULL)
Not tested, but I wonder if it works if you move libosmo-pfcp.la before $(LIBOSMOCORE_LIBS). I just saw it like that in an osmo-bsc test.
On Mon, Nov 21, 2022 at 06:17:08PM +0700, Vadim Yanitskiy wrote:
there's actually two binaries generated during the build process:
- tests/libosmo-pfcp/.libs/pfcp_test (generated by `make`)
- tests/libosmo-pfcp/.libs/lt-pfcp_test (generated by `make check`)
Curious, I see only the one, only pfcp_test, no lt-pfcp_test here.
On Mon, Nov 21, 2022 at 12:38:08PM +0100, Oliver Smith wrote:
Hi Neels,
On 21.11.22 01:00, Neels Hofmeyr wrote:
I try to accomplish this by:
pfcp_test_LDADD = \ $(LIBOSMOCORE_LIBS) \ $(top_builddir)/src/libosmo-pfcp/libosmo-pfcp.la \ $(top_builddir)/src/libosmo-gtlv/libosmo-gtlv.la \ $(NULL)
Not tested, but I wonder if it works if you move libosmo-pfcp.la before $(LIBOSMOCORE_LIBS). I just saw it like that in an osmo-bsc test.
Actually indeed yes that helps -- but WHY!?!?!?!? how does the position of LIBOSMOCORE_LIBS make a difference for the loading source for other libs?
Here's a diff of the relevant parts of the build tree before moving LIBOSMOCORE_LIBS down and after, weird how that LD_LIBRARY_PATH suddenly moves /usr/local/lib to the last position. Must be some deliberate magic.
Binary files saved_libosmo-pfcp/tests/libosmo-pfcp/.libs/pfcp_test and libosmo-pfcp/tests/libosmo-pfcp/.libs/pfcp_test differ diff -u -r saved_libosmo-pfcp/tests/libosmo-pfcp/Makefile libosmo-pfcp/tests/libosmo-pfcp/Makefile --- saved_libosmo-pfcp/tests/libosmo-pfcp/Makefile 2022-11-21 12:41:49.057361923 +0100 +++ libosmo-pfcp/tests/libosmo-pfcp/Makefile 2022-11-21 12:42:34.197397597 +0100 @@ -106,9 +106,10 @@ am_pfcp_test_OBJECTS = pfcp_test.$(OBJEXT) pfcp_test_OBJECTS = $(am_pfcp_test_OBJECTS) am__DEPENDENCIES_1 = -pfcp_test_DEPENDENCIES = $(am__DEPENDENCIES_1) \ +pfcp_test_DEPENDENCIES = \ $(top_builddir)/src/libosmo-pfcp/libosmo-pfcp.la \ - $(top_builddir)/src/libosmo-gtlv/libosmo-gtlv.la + $(top_builddir)/src/libosmo-gtlv/libosmo-gtlv.la \ + $(am__DEPENDENCIES_1) AM_V_lt = $(am__v_lt_$(V)) am__v_lt_ = $(am__v_lt_$(AM_DEFAULT_VERBOSITY)) am__v_lt_0 = --silent @@ -320,9 +321,9 @@ $(NULL)
pfcp_test_LDADD = \ - $(LIBOSMOCORE_LIBS) \ $(top_builddir)/src/libosmo-pfcp/libosmo-pfcp.la \ $(top_builddir)/src/libosmo-gtlv/libosmo-gtlv.la \ + $(LIBOSMOCORE_LIBS) \ $(NULL)
all: all-am diff -u -r saved_libosmo-pfcp/tests/libosmo-pfcp/pfcp_test libosmo-pfcp/tests/libosmo-pfcp/pfcp_test --- saved_libosmo-pfcp/tests/libosmo-pfcp/pfcp_test 2022-11-21 12:41:51.533363886 +0100 +++ libosmo-pfcp/tests/libosmo-pfcp/pfcp_test 2022-11-21 12:42:34.417397771 +0100 @@ -188,7 +188,7 @@
if test -f "$progdir/$program"; then # Add our own library path to LD_LIBRARY_PATH - LD_LIBRARY_PATH="/usr/local/lib:/home/old/osmo-dev/make/libosmo-pfcp/src/libosmo-pfcp/.libs:/home/old/osmo-dev/make/libosmo-pfcp/src/libosmo-gtlv/.libs:$LD_LIBRARY_PATH" + LD_LIBRARY_PATH="/home/old/osmo-dev/make/libosmo-pfcp/src/libosmo-pfcp/.libs:/home/old/osmo-dev/make/libosmo-pfcp/src/libosmo-gtlv/.libs:/usr/local/lib:$LD_LIBRARY_PATH"
# Some systems cannot cope with colon-terminated LD_LIBRARY_PATH # The second colon is a workaround for a bug in BeOS R4 sed
Thanks for your help everyone!
~N
On 11/21/22 18:53, Neels Hofmeyr wrote:
diff -u -r saved_libosmo-pfcp/tests/libosmo-pfcp/pfcp_test libosmo-pfcp/tests/libosmo-pfcp/pfcp_test --- saved_libosmo-pfcp/tests/libosmo-pfcp/pfcp_test 2022-11-21 12:41:51.533363886 +0100 +++ libosmo-pfcp/tests/libosmo-pfcp/pfcp_test 2022-11-21 12:42:34.417397771 +0100 @@ -188,7 +188,7 @@
if test -f "$progdir/$program"; then # Add our own library path to LD_LIBRARY_PATH
- LD_LIBRARY_PATH="/usr/local/lib:/home/old/osmo-dev/make/libosmo-pfcp/src/libosmo-pfcp/.libs:/home/old/osmo-dev/make/libosmo-pfcp/src/libosmo-gtlv/.libs:$LD_LIBRARY_PATH"
- LD_LIBRARY_PATH="/home/old/osmo-dev/make/libosmo-pfcp/src/libosmo-pfcp/.libs:/home/old/osmo-dev/make/libosmo-pfcp/src/libosmo-gtlv/.libs:/usr/local/lib:$LD_LIBRARY_PATH"
I see no LD_LIBRARY_PATH in my version of the 'pfcp_test' script at all! In case you're curious, find it attached. I assume this might be related to the configure script finding or not finding some tools, so attaching my config.log too.
I am using:
automake (GNU automake) 1.16.5 autoconf (GNU Autoconf) 2.71 libtoolize (GNU libtool) 2.4.7 (Debian Unstable)
I have exactly the same versions (Arch Linux).
Best regards, Vadim.
-
Neels Hofmeyr -
Oliver Smith -
Vadim Yanitskiy