dev-util/lttng-tools: fix build with slibtool

Closes: https://bugs.gentoo.org/858095
Closes: https://bugs.gentoo.org/924437
Upstream-PR: https://github.com/lttng/lttng-tools/pull/169
Upstream-Commit: https://github.com/lttng/lttng-tools/commit/bb1c9fc3f89c2faffb0228c0b77e32653e018a23
Signed-off-by: orbea <orbea@riseup.net>
Closes: https://github.com/gentoo/gentoo/pull/35825
Signed-off-by: Joonas Niilola <juippis@gentoo.org>

2 files changed, 99 insertions, 1 deletions

diff --git a/dev-util/lttng-tools/files/lttng-tools-2.13.9-slibtool.patch b/dev-util/lttng-tools/files/lttng-tools-2.13.9-slibtool.patch
new file mode 100644
index 000000000000..634bd388b44c
--- /dev/null
+++ b/dev-util/lttng-tools/files/lttng-tools-2.13.9-slibtool.patch
@@ -0,0 +1,87 @@
+https://github.com/lttng/lttng-tools/pull/169
+https://github.com/lttng/lttng-tools/commit/bb1c9fc3f89c2faffb0228c0b77e32653e018a23
+
+From bb1c9fc3f89c2faffb0228c0b77e32653e018a23 Mon Sep 17 00:00:00 2001
+From: orbea <orbea@riseup.net>
+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=UTF-8
+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 <orbea@riseup.net>
+Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
+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
diff --git a/dev-util/lttng-tools/lttng-tools-2.13.9.ebuild b/dev-util/lttng-tools/lttng-tools-2.13.9.ebuild
index 9375115c5205..ce9797cfbfb1 100644
--- a/dev-util/lttng-tools/lttng-tools-2.13.9.ebuild
+++ b/dev-util/lttng-tools/lttng-tools-2.13.9.ebuild
@@ -3,7 +3,7 @@
 
 EAPI=8
 
-inherit flag-o-matic
+inherit autotools flag-o-matic
 
 # Please bump the following packages together:
 # dev-util/lttng-modules
@@ -37,6 +37,17 @@ QA_CONFIG_IMPL_DECL_SKIP=(
 	pthread_set_name_np # different from pthread_setname_*, not on linux
 )
 
+PATCHES=(
+	# https://bugs.gentoo.org/858095
+	# https://github.com/lttng/lttng-tools/pull/169
+	"${FILESDIR}"/${PN}-2.13.9-slibtool.patch
+)
+
+src_prepare() {
+	default
+	eautoreconf
+}
+
 src_configure() {
 	# bug 906928
 	use elibc_musl && append-cppflags -D_LARGEFILE64_SOURCE