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