commit: 0d90e8ffabbb45afe3f8bb6137172265153313bd Author: orbea <orbea <AT> riseup <DOT> net> AuthorDate: Tue Mar 19 00:57:54 2024 +0000 Commit: Joonas Niilola <juippis <AT> gentoo <DOT> org> CommitDate: Mon Apr 15 06:32:24 2024 +0000 URL: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=0d90e8ff
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 <AT> riseup.net> Closes: https://github.com/gentoo/gentoo/pull/35825 Signed-off-by: Joonas Niilola <juippis <AT> gentoo.org> .../files/lttng-tools-2.13.9-slibtool.patch | 87 ++++++++++++++++++++++ dev-util/lttng-tools/lttng-tools-2.13.9.ebuild | 13 +++- 2 files changed, 99 insertions(+), 1 deletion(-) 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 <[email protected]> +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 <[email protected]> +Signed-off-by: Jérémie Galarneau <[email protected]> +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
