Corruption on a binary generated during packaging

ycollet · May 30, 2025, 1:45pm

Hello,

I have a package that build fine for years on Feodra. And now, on Fedora 42, the binary segfault and I am not able to load the debug symbols in gdb.
I suspect a corruption problem.
For Fedora 41, the messages related to debug symbolds extraction are the following:

find-debuginfo: starting
Extracting debug info from 7 files
DWARF-compressing 7 files

On Fedora 42, the messages are the following:

find-debuginfo: starting
Extracting debug info from 7 files
objcopy: /builddir/build/BUILD/BespokeSynth-weekly-1.3.10-build/BUILDROOT/usr/bin/stBaNPZD: warning: allocated section `.note.gnu.build-id' not in segment
objcopy: /builddir/build/BUILD/BespokeSynth-weekly-1.3.10-build/BUILDROOT/usr/bin/stBaNPZD: warning: allocated section `.init' not in segment
objcopy: /builddir/build/BUILD/BespokeSynth-weekly-1.3.10-build/BUILDROOT/usr/bin/stBaNPZD: warning: allocated section `.plt' not in segment
objcopy: /builddir/build/BUILD/BespokeSynth-weekly-1.3.10-build/BUILDROOT/usr/bin/stBaNPZD: warning: allocated section `.plt.sec' not in segment
objcopy: /builddir/build/BUILD/BespokeSynth-weekly-1.3.10-build/BUILDROOT/usr/bin/stBaNPZD: warning: allocated section `.text' not in segment
objcopy: /builddir/build/BUILD/BespokeSynth-weekly-1.3.10-build/BUILDROOT/usr/bin/stBaNPZD: warning: allocated section `.fini' not in segment
objcopy: /builddir/build/BUILD/BespokeSynth-weekly-1.3.10-build/BUILDROOT/usr/bin/stBaNPZD: warning: allocated section `.interp' not in segment
objcopy: /builddir/build/BUILD/BespokeSynth-weekly-1.3.10-build/BUILDROOT/usr/bin/stBaNPZD: warning: allocated section `.gnu.hash' not in segment
objcopy: /builddir/build/BUILD/BespokeSynth-weekly-1.3.10-build/BUILDROOT/usr/bin/stBaNPZD: warning: allocated section `.dynsym' not in segment
objcopy: /builddir/build/BUILD/BespokeSynth-weekly-1.3.10-build/BUILDROOT/usr/bin/stBaNPZD: warning: allocated section `.gnu.version' not in segment
objcopy: /builddir/build/BUILD/BespokeSynth-weekly-1.3.10-build/BUILDROOT/usr/bin/stBaNPZD: warning: allocated section `.gnu.version_r' not in segment
objcopy: /builddir/build/BUILD/BespokeSynth-weekly-1.3.10-build/BUILDROOT/usr/bin/stBaNPZD: warning: allocated section `.rela.dyn' not in segment
objcopy: /builddir/build/BUILD/BespokeSynth-weekly-1.3.10-build/BUILDROOT/usr/bin/stBaNPZD: warning: allocated section `.rela.plt' not in segment
objcopy: /builddir/build/BUILD/BespokeSynth-weekly-1.3.10-build/BUILDROOT/usr/bin/stBaNPZD: warning: allocated section `.relr.dyn' not in segment
objcopy: /builddir/build/BUILD/BespokeSynth-weekly-1.3.10-build/BUILDROOT/usr/bin/stBaNPZD: warning: allocated section `.rodata' not in segment
objcopy: /builddir/build/BUILD/BespokeSynth-weekly-1.3.10-build/BUILDROOT/usr/bin/stBaNPZD: warning: allocated section `.eh_frame_hdr' not in segment
objcopy: /builddir/build/BUILD/BespokeSynth-weekly-1.3.10-build/BUILDROOT/usr/bin/stBaNPZD: warning: allocated section `.eh_frame' not in segment
objcopy: /builddir/build/BUILD/BespokeSynth-weekly-1.3.10-build/BUILDROOT/usr/bin/stBaNPZD: warning: allocated section `.gcc_except_table' not in segment
objcopy: /builddir/build/BUILD/BespokeSynth-weekly-1.3.10-build/BUILDROOT/usr/bin/stBaNPZD: warning: allocated section `.note.gnu.property' not in segment
objcopy: /builddir/build/BUILD/BespokeSynth-weekly-1.3.10-build/BUILDROOT/usr/bin/stBaNPZD: warning: allocated section `.note.ABI-tag' not in segment
objcopy: /builddir/build/BUILD/BespokeSynth-weekly-1.3.10-build/BUILDROOT/usr/bin/stBaNPZD: warning: allocated section `.note.package' not in segment
objcopy: /builddir/build/BUILD/BespokeSynth-weekly-1.3.10-build/BUILDROOT/usr/bin/stBaNPZD: warning: allocated section `.init_array' not in segment
objcopy: /builddir/build/BUILD/BespokeSynth-weekly-1.3.10-build/BUILDROOT/usr/bin/stBaNPZD: warning: allocated section `.fini_array' not in segment
objcopy: /builddir/build/BUILD/BespokeSynth-weekly-1.3.10-build/BUILDROOT/usr/bin/stBaNPZD: warning: allocated section `.data.rel.ro' not in segment
objcopy: /builddir/build/BUILD/BespokeSynth-weekly-1.3.10-build/BUILDROOT/usr/bin/stBaNPZD: warning: allocated section `.got' not in segment
objcopy: /builddir/build/BUILD/BespokeSynth-weekly-1.3.10-build/BUILDROOT/usr/bin/stBaNPZD: warning: allocated section `.data' not in segment
objcopy: /builddir/build/BUILD/BespokeSynth-weekly-1.3.10-build/BUILDROOT/usr/bin/stBaNPZD: warning: allocated section `.dynstr' not in segment
objcopy: /builddir/build/BUILD/BespokeSynth-weekly-1.3.10-build/BUILDROOT/usr/bin/stBaNPZD: warning: allocated section `.dynamic' not in segment
DWARF-compressing 7 files

The link to the COPR build:

Is this a known problem ?

I tried both gcc and clang and the problem is the same.
I saw a build of a package with a failure during link … Don’t remember which one.

ycollet · May 30, 2025, 1:48pm

For this package, I used patchelf to add a RPATH. Maybe this tool is responsible of this problem. But this has worked for years too until Fedora 42.

barryascott · May 30, 2025, 3:47pm

Try the build with that step ommitted to see if your guess is good

Can’t you add an rpath with options in the link?

ycollet · May 30, 2025, 7:02pm

So, I commented out the call to patchelf and after installing the package, I set the LD_LIBRARY_PATH, just to do the job done by patchelf and it worked.
So, patchelf is corrupting the binary …

ycollet · May 30, 2025, 7:12pm

Found that patchelf can corrupt binaries …

github.com/NixOS/patchelf

Using patchelf and llvm-strip in sequence corrupts ELF files

ouvert 12:16PM - 14 Jul 23 UTC

mologie

bug

**Describe the bug** Running `patchelf` on any ELF file causes `llvm-strip-14…` to corrupt it afterwards. (One might argue that this is an llvm-strip bug, and it probably is, but patchelf might be able to produce an ELF file in a format that's still processable with LLVM.) Affects: All patchelf versions from 0.14 to 0.18 that I tested, LLVM 14 and 15 **Steps To Reproduce** tl;dr: Run `patchelf --set-rpath '$ORIGIN'` on any binary, then run `llvm-strip` with standard args on it. The output is always corrupted. Use an Ubuntu 22.04 image and install `llvm-14-tools` for `llvm-strip-14`. (`llvm-15-tools` is similarly affected.) ``` $ wget https://github.com/NixOS/patchelf/releases/download/0.18.0/patchelf-0.18.0-x86_64.tar.gz [...] $ tar xf patchelf-0.18.0-x86_64.tar.gz $ export PATH=$PWD/bin:$PATH $ echo 'int main() { return 0; }' > a.c $ clang -Os -o a a.c $ file a a: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=5a1afb6fe3c09ec9355fe3dfe35d4160dadb606d, for GNU/Linux 3.2.0, not stripped $ ./a $ llvm-strip --version llvm-strip, compatible with GNU strip Ubuntu LLVM version 14.0.0 Optimized build. Default target: x86_64-pc-linux-gnu Host CPU: skylake $ clang --version Ubuntu clang version 14.0.0-1ubuntu1 Target: x86_64-pc-linux-gnu Thread model: posix InstalledDir: /usr/bin $ patchelf --version patchelf 0.18.0 $ llvm-strip -o a.stripped a $ ./a.stripped $ patchelf --set-rpath '$ORIGIN' --output a.patched a $ ./a.patched $ llvm-strip -o a.patched.stripped a.patched $ ldd a.patched.stripped not a dynamic executable $ file a.patched.stripped a.patched.stripped: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=5a1afb6fe3c09ec9355fe3dfe35d4160dadb606d, for GNU/Linux 3.2.0, stripped $ ./a.patched.stripped [1] 31807 segmentation fault ./a.patched.stripped ``` The `a.*` binaries are attached: [patchelf-strip-corruption.tar.gz](https://github.com/NixOS/patchelf/files/12050261/patchelf-strip-corruption.tar.gz) **Expected behavior** I expected `llvm-strip` to work. Specifically, I'd have expected the `ldd a.patched.stripped` command to report that it's still a dynamic executable, and `./a.patched.stripped` should not have segfaulted. **`patchelf --version` output** `patchelf 0.18.0` **Additional context** Files in this report are from Ubuntu 22.04 x86_64, but it appears to happen on any OS and with any LLVM distribution. Gave Arch Linux x86_64 and Ubuntu for arm64 a shot. Strip from binutils does not corrupt the ELF files.

ycollet · May 30, 2025, 8:34pm

Found a solution: still using patchelf, but I uses mold as a linker instead of ld.
Used this cmake flag:

-DCMAKE_EXE_LINKER_FLAGS="-fuse-ld=mold"

barryascott · May 31, 2025, 7:38am

Why not use ld’s -rpath? From Using LD, the GNU linker - Options

-rpath dir
Add a directory to the runtime library search path. This is used when linking an ELF executable with shared objects. All -rpath arguments are concatenated and passed to the runtime linker, which uses them to locate shared objects at runtime. The -rpath option is also used when locating shared objects which are needed by shared objects explicitly included in the link; see the description of the -rpath-link option. If -rpath is not used when linking an ELF executable, the contents of the environment variableLD_RUN_PATH will be used if it is defined. The -rpath option may also be used on SunOS. By default, on SunOS, the linker will form a runtime search patch out of all the -Loptions it is given. If a -rpath option is used, the runtime search path will be formed exclusively using the -rpath options, ignoring the -L options. This can be useful when using gcc, which adds many -L options which may be on NFS mounted filesystems. For compatibility with other ELF linkers, if the -R option is followed by a directory name, rather than a file name, it is treated as the -rpath option.

Topic		Replies	Views
EMBOSS binaries segfault on my fedora38 - Should I file a bug? Ask Fedora problem , f38	2	151	October 4, 2023
Cross-compiling failure with segfault, no debuginfo package Ask Fedora f34	3	889	February 24, 2022
[Packaging] gdb memory leak? Ask Fedora	3	51	May 6, 2025
Silverblue fsck-detected corruption Ask Fedora rpm-ostree , nvidia , silverblue , f40	9	321	October 22, 2024
Is it normal that libasound.so.2.0.0 is completely stripped from all symbols? Ask Fedora f41	1	135	November 24, 2024

Corruption on a binary generated during packaging

Related topics