When linking png images as binary objects ld crashes: ld -r -b binary -z noexecstack xputty_logo.png -o xputty_logo.o This is executed in mock when compiling guitarix-0.47.0 for rawhide. Reproducible: Always Steps to Reproduce: 1. Link a png image as a binary object Actual Results: Segmentation fault (core dumped) ld -r -b binary -z noexecstack xputty_logo.png -o xputty_logo.o The coredump is not created inside the mock chroot Expected Results: The image links to a reloacatable object Additional Information: binutils-2.43.1-14.fc41.x86_64 do not have this problem
After changing coredump limit, a coredump is created, but it reports the host package version: PID: 87525 (ld) UID: 0 (root) GID: 0 (root) Signal: 11 (SEGV) Timestamp: Sat 2026-01-24 20:50:41 CET (3min 58s ago) Command Line: ld -r -b binary -z noexecstack xputty_logo.png -o t3.o Executable: /usr/bin/ld.bfd Control Group: /machine.slice/machine-6bf11709e5494284a7c1ffbe69fe14df.scope/payload Unit: machine-6bf11709e5494284a7c1ffbe69fe14df.scope Slice: machine.slice Boot ID: 933c0d1c4dd44b2d842e1c1e26cb84c9 Machine ID: f334e89d9e9b4f1ebf6c14577bc78978 Hostname: 6bf11709e5494284a7c1ffbe69fe14df Storage: /var/lib/systemd/coredump/core.ld.0.933c0d1c4dd44b2d842e1c1e26cb84c9.87525.1769284241000000.zst (present) Size on Disk: 74.1K Package: binutils/2.43.1-14.fc41 build-id: 488efd0d1ec4b549dccca5737f3176d7a8e2e499 Message: Process 87525 (ld) of user 0 dumped core. Module /usr/bin/ld.bfd from rpm binutils-2.43.1-14.fc41.x86_64 Stack trace of thread 37: #0 0x0000559b3f8b01ac map_input_to_output_sections.isra.0 (/usr/bin/ld.bfd + 0x4b1ac) #1 0x0000559b3f884dd8 gldi386pep_list_options.lto_priv.0 (/usr/bin/ld.bfd + 0x1fdd8) #2 0x0000559b3f868934 main (/usr/bin/ld.bfd + 0x3934) #3 0x00007f749df27681 n/a (/usr/lib64/libc.so.6 + 0x3681) #4 0x00007f749df27798 n/a (/usr/lib64/libc.so.6 + 0x3798) #5 0x0000559b3f86a7d5 main (/usr/bin/ld.bfd + 0x57d5) ELF object binary architecture: AMD x86-64
Bactrace: Program terminated with signal SIGSEGV, Segmentation fault. #0 0x0000559b3f8b01ac in ldelf_after_open.constprop.0 (use_libpath=1, native=1, elfsize=64, prefix=0x559b3f8c5afd "/usr", is_freebsd=0, is_linux=1) at ../../ld/ldelf.c:1333 1333 elf_section_type (s) = SHT_NOTE; (gdb) bt #0 0x0000559b3f8b01ac in ldelf_after_open.constprop.0 (use_libpath=1, native=1, elfsize=64, prefix=0x559b3f8c5afd "/usr", is_freebsd=0, is_linux=1) at ../../ld/ldelf.c:1333 #1 0x0000559b3f884dd8 in ldemul_after_open () at ../../ld/ldemul.c:80 #2 lang_process () at ../../ld/ldlang.c:8563 #3 0x0000559b3f868934 in main (argc=9, argv=<optimized out>) at ../../ld/ldmain.c:958
Noticed the same for my mupdf builds in rawhide. Further info: Build worked during the mass rebuild, i.e. with binutils from that buildroot. Build works on aarch64 and ppc64le (koji scratch), but no other arch: https://koji.fedoraproject.org/koji/taskinfo?taskID=141553683
In terms of fedora/dist-git rawhide commits, I bisected this to: 27063804ceed9b9d7b9c1628ac8a6725d45d8a02 is the first bad commit commit 27063804ceed9b9d7b9c1628ac8a6725d45d8a02 (origin/rawhide, origin/main, origin/HEAD, rawhide) Author: Nick Clifton <nickc> Date: Mon Jan 19 10:29:29 2026 +0000 Rebase to commit ba5838a98fb
Think this should be https://sourceware.org/PR33780 and it's fixed already upstream.
(In reply to Sam James from comment #5) > Think this should be https://sourceware.org/PR33780 and it's fixed already > upstream. Yep, with that commit on top of current rawhide, I don't have that segfault any more on x86_64. (Haven't checked the contents of the .o, though.)
No more issue with the latest build : binutils-2.45.90-1.fc44.
*** Bug 2435975 has been marked as a duplicate of this bug. ***
I can confirm that binutils-2.45.90-1.fc44.x86_64 solves my package's FTBFS in local mock. The update is sitting in testing, though, due to some CI hick-up. Would be nice to have this in F44 no matter the branching.
Please note that the build fixing this has been unpushed because of the branch event. Please rebuild and resubmit.
We have binutils-2.46-1 in f44 buildroot, so I expect this issue is fixed now.