From bb1c9fc3f89c2faffb0228c0b77e32653e018a23 Mon Sep 17 00:00:00 2001 From: orbea Date: Fri, 8 Mar 2024 08:17:37 -0800 Subject: [PATCH] Fix: baddr-statedump: use $(LIBTOOL) --mode=execute MIME-Version: 1.0 Content-Type: text/plain; charset=utf8 Content-Transfer-Encoding: 8bit GNU libtool inconsistently places the compiled executable in the source directory or in the .libs directory where a libtool wrapper script is placed in the source directory. While slibtool will always place the compiled executable in the .libs directory and a wrapper script in the source directory. This will result with a build error when using slibtool since objcopy needs the executable and not the shell wrapper script, but this can be solved for both implementations by using $(LIBTOOL) --mode=execute on all commands that operate on the libtool compiled executables. Gentoo issue: https://bugs.gentoo.org/858095 The GNU libtool --mode=excute is documented upstream. https://www.gnu.org/software/libtool/manual/html_node/Execute-mode.html https://www.gnu.org/software/libtool/manual/html_node/Debugging-executables.html And the GNU libtool behavior of when to create a wrapper script is documented in the 'Linking Executables' section. "Notice that the executable, hell, was actually created in the .libs subdirectory. Then, a wrapper script (or, on certain platforms, a wrapper executable see Wrapper executables) was created in the current directory. Since libtool created a wrapper script, you should use libtool to install it and debug it too. However, since the program does not depend on any uninstalled libtool library, it is probably usable even without the wrapper script." https://www.gnu.org/software/libtool/manual/html_node/Linking-executables.html And the inconsistency between GNU libtool and slibtool is documented at the Gentoo wiki. "One difference between GNU libtool and slibtool is that the former will conditionally place the compiled executable or a shell wrapper script in the build directory, depending on whether or not the executable depends on a build-local libtool library (e.g. libfoo.la). Where slibtool will always place a compatible wrapper script in the build directory where GNU libtool would have conditionally placed the executable. When the wrapper script is created both GNU libtool and slibtool will place the executable in the .libs directory within the build directory. Consequently build systems, ebuilds, and other users should take care to avoid scenarios like installing the wrapper script to the system instead of the executable. In these cases ideally the executable would be installed by the same libtool implementation that compiled it." https: //wiki.gentoo.org/wiki/Slibtool#Installing_or_using_binaries_created_by_libtool_manually Signed-off-by: orbea Signed-off-by: Jérémie Galarneau Change-Id: I03102ed78af835daa9b9a5836c2979a5f5d4bd8c --- tests/regression/ust/baddr-statedump/Makefile.am | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tests/regression/ust/baddr-statedump/Makefile.am b/tests/regression/ust/baddr-statedump/Makefile.am index f8fe26395..d37dbb6dd 100644 --- a/tests/regression/ust/baddr-statedump/Makefile.am +++ b/tests/regression/ust/baddr-statedump/Makefile.am @@ -19,11 +19,11 @@ EXTRA_DIST = test_baddr-statedump test_baddr-statedump.py # Extract debug symbols prog.debug: prog - $(objcopy_verbose)$(OBJCOPY) --only-keep-debug prog prog.debug + $(objcopy_verbose)$(LIBTOOL) --mode=execute $(OBJCOPY) --only-keep-debug prog prog.debug # Strip and add debuglink prog.strip: prog.debug - @cp -f prog prog.strip + @$(LIBTOOL) --mode=execute cp -f prog prog.strip $(objcopy_verbose)$(OBJCOPY) --strip-debug --add-gnu-debuglink=prog.debug prog.strip all-local: prog.strip -- 2.34.1