Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
wants to merge 1 commit into from
Closed
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
87 changes: 87 additions & 0 deletions 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
13 changes: 12 additions & 1 deletion dev-util/lttng-tools/lttng-tools-2.13.9.ebuild
Expand Up @@ -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
Expand Down Expand Up @@ -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
Expand Down