Summary: | sys-apps/fd-10.2.0: segfault on musl system | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Wolfgang Müller <wolf> |
Component: | Current packages | Assignee: | James Le Cuirot <chewi> |
Status: | RESOLVED FIXED | ||
Severity: | critical | CC: | chewi, mgorny, wolf |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
See Also: |
https://bugs.gentoo.org/show_bug.cgi?id=922372 https://bugs.gentoo.org/show_bug.cgi?id=938847 https://bugs.gentoo.org/show_bug.cgi?id=937470 |
||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
readelf -a for the segfaulting binary
readelf -a for the working binary |
Description
Wolfgang Müller
2024-09-24 09:21:50 UTC
I investigated some more (mainly comparing build environments) and was able to narrow it down to the ebuild environment setting `-Wl,-z,pack-relative-relocs`. If I use filter-flags to remove those flags from the build, fd works correctly again. Created attachment 904173 [details]
readelf -a for the segfaulting binary
Since I'm out of my depth here I'm attaching the readelf output for both the working and the segfaulting binary. It seems that in the one that was built with pack-relative-relocs the entire .relr.dyn section is empty (or corrupted?)
Created attachment 904174 [details]
readelf -a for the working binary
Okay, one more piece of information... I don't think sys-apps/fd is dynamically linked. In fact, trying to build sys-apps/ripgrep-14.1.1 (I still have 14.1.0-r1 installed from 2024-07-29, which is dynamically linked) fails with = note: /usr/lib/gcc/x86_64-pc-linux-musl/13/../../../../x86_64-pc-linux-musl/bin/ld: cannot find -lpcre2-8: No such file or directory collect2: error: ld returned 1 exit status error: could not compile `ripgrep` (bin "rg") due to 1 previous error even though https://bugs.gentoo.org/922372 should have been fixed. At this point I'm very confused as to what exactly is going on. I think I finally found the underlying issue. A recent change to cargo.eclass [1] changed it such that local -x CARGO_TARGET_"${TRIPLE}"_RUSTFLAGS="-C strip=none -C linker=${LD_A[0]}" is run even outside of a cross-compiling environment, overriding the value set in /etc/env.d/50rust-bin-1.80.1, which disables support for static compilation: CARGO_TARGET_X86_64_UNKNOWN_LINUX_MUSL_RUSTFLAGS="-C target-feature=-crt-static" Ever since [1], rust packages on musl have been built statically and not dynamically. This should explain all related issues as well (some of which seem to have been solved by setting `-C target-feature=-crt-static` locally in the ebuild.) After editing the eclass to contain `-C target-feature=-crt-static` in CARGO_TARGET_X86_64_UNKNOWN_LINUX_MUSL_RUSTFLAGS, both sys-apps/fd and sys-apps/ripgrep build again, are linked dynamically, and run without issue. [1] https://gitweb.gentoo.org/repo/gentoo.git/commit/eclass/cargo.eclass?id=27d469a2114b4ad0b3e682854c50c806753eb472 My apologies. I was vaguely aware that musl defaults to static, but I didn't know we changed that default like this. I thought about adding this flag to the eclass unconditionally because I doubt we ever want crt-static. I thought we could even drop the variable from the Rust packages, but that would assume that Cargo is the only way to build Rust code. Let's just respect the variable by appending to it instead since I don't think there's any harm in that. Please could you test the following tiny change.
> @@ -585,7 +585,7 @@ cargo_env() {
> local -x CARGO_BUILD_TARGET=$(rust_abi)
> local TRIPLE=${CARGO_BUILD_TARGET//-/_}
> local TRIPLE=${TRIPLE^^} LD_A=( $(tc-getCC) ${LDFLAGS} )
> - local -x CARGO_TARGET_"${TRIPLE}"_RUSTFLAGS="-C strip=none -C linker=${LD_A[0]}"
> + local -x CARGO_TARGET_"${TRIPLE}"_RUSTFLAGS+=" -C strip=none -C linker=${LD_A[0]}"
> [[ ${#LD_A[@]} -gt 1 ]] && local CARGO_TARGET_"${TRIPLE}"_RUSTFLAGS+="$(printf -- ' -C link-arg=%s' "${LD_A[@]:1}")"
> local CARGO_TARGET_"${TRIPLE}"_RUSTFLAGS+=" ${RUSTFLAGS}"
Sorry, it was late and I messed that up. Try tihs.
> --- a/eclass/cargo.eclass
> +++ b/eclass/cargo.eclass
> @@ -584,10 +584,10 @@ cargo_env() {
> # into link-args along with LDFLAGS.
> local -x CARGO_BUILD_TARGET=$(rust_abi)
> local TRIPLE=${CARGO_BUILD_TARGET//-/_}
> - local TRIPLE=${TRIPLE^^} LD_A=( $(tc-getCC) ${LDFLAGS} )
> - local -x CARGO_TARGET_"${TRIPLE}"_RUSTFLAGS="-C strip=none -C linker=${LD_A[0]}"
> - [[ ${#LD_A[@]} -gt 1 ]] && local CARGO_TARGET_"${TRIPLE}"_RUSTFLAGS+="$(printf -- ' -C link-arg=%s' "${LD_A[@]:1}")"
> - local CARGO_TARGET_"${TRIPLE}"_RUSTFLAGS+=" ${RUSTFLAGS}"
> + local CTTR_VAR=CARGO_TARGET_${TRIPLE^^}_RUSTFLAGS LD_A=( $(tc-getCC) ${LDFLAGS} )
> + local -x "${CTTR_VAR}"="${!CTTR_VAR} -C strip=none -C linker=${LD_A[0]}"
> + [[ ${#LD_A[@]} -gt 1 ]] && local "${CTTR_VAR}"+="$(printf -- ' -C link-arg=%s' "${LD_A[@]:1}")"
> + local "${CTTR_VAR}"+=" ${RUSTFLAGS}"
>
> (
> # These variables will override the above, even if empty, so unset them
Yeah, the previous change wouldn't work because the local command shadows previous scopes completely and the environment variable is not inherited. You can make local inherit the existing variable with the -I flag however. No need for a more complicated setup. I've successfully tested the following on my system:
> @@ -585,7 +585,7 @@ cargo_env() {
> local -x CARGO_BUILD_TARGET=$(rust_abi)
> local TRIPLE=${CARGO_BUILD_TARGET//-/_}
> local TRIPLE=${TRIPLE^^} LD_A=( $(tc-getCC) ${LDFLAGS} )
> - local -x CARGO_TARGET_"${TRIPLE}"_RUSTFLAGS="-C strip=none -C linker=${LD_A[0]}"
> + local -Ix CARGO_TARGET_"${TRIPLE}"_RUSTFLAGS+=" -C strip=none -C linker=${LD_A[0]}"
> [[ ${#LD_A[@]} -gt 1 ]] && local CARGO_TARGET_"${TRIPLE}"_RUSTFLAGS+="$(printf -- ' -C link-arg=%s' "${LD_A[@]:1}")"
> local CARGO_TARGET_"${TRIPLE}"_RUSTFLAGS+=" ${RUSTFLAGS}"
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=b4ca7760f8bb83e8d6180d6be48dcbd7af8b3498 commit b4ca7760f8bb83e8d6180d6be48dcbd7af8b3498 Author: James Le Cuirot <chewi@gentoo.org> AuthorDate: 2024-10-01 20:37:51 +0000 Commit: James Le Cuirot <chewi@gentoo.org> CommitDate: 2024-10-01 20:37:51 +0000 cargo.eclass: Respect existing CARGO_TARGET_${TRIPLE}_RUSTFLAGS This variable is used to disable crt-static with musl. Closes: https://bugs.gentoo.org/940197 Signed-off-by: James Le Cuirot <chewi@gentoo.org> eclass/cargo.eclass | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Nice trick, thank you! I've given talks on Bash before, but that had escaped me. |