Hello,

The patchelf package in Guix is currently at 0.18.0. Starting with that
release, patchelf overwrites the header sections it replaces with garbage
by default. .NET "single-file" executables locate their appended payload
by reading an offset stored inside the binary itself, so this corrupts
them. The resulting program aborts immediately at startup:

  Failure processing application bundle; possible file corruption.
  Arithmetic overflow while reading bundle.
  A fatal error occurred while processing application bundle

Upstream added --no-clobber-old-sections for exactly this class of binary
(programs that read their own headers at fixed offsets). That flag does
not exist in 0.18.0; it is available in 0.19.0.


Reproducer:

  wget 
https://github.com/slskd/slskd/releases/download/0.26.0/slskd-0.26.0-linux-x64.zip
  mkdir t && cd t && unzip ../slskd-0.26.0-linux-x64.zip
  cp slskd slskd.test
  LOADER=$(guix build glibc | grep -E 'glibc-[0-9.]+$')/lib/ld-linux-x86-64.so.2
  guix shell patchelf -- patchelf --set-interpreter "$LOADER" slskd.test
  ./slskd.test

This produces the bundle error above. Building patchelf 0.19.0 locally and
repeating the same command with --no-clobber-old-sections added produces a
binary that starts normally.


Impact:

Any package that runs patchelf over a .NET single-file release is silently
broken -- including packages built with nonguix's binary-build-system,
whose #:patchelf-plan invokes patchelf internally. The build succeeds and
the corruption only surfaces at runtime, which makes it easy to attribute
to the upstream binary rather than to patchelf.

This regressed for me across recent guix pulls with no change at all to my
package definition: same source archive, same recipe, previously working
output, now a binary that cannot start.


Suggested fix:

Update patchelf to 0.19.0. Note that the version bump alone is not
sufficient for affected packages -- 0.19.0 does not change the default
behaviour, it only adds the opt-out -- so users must also pass
--no-clobber-old-sections. It may be worth mentioning this in the manual
alongside the binary-packaging guidance, since nothing in the failure mode
points at patchelf.

guix describe:
Generation 34   Jul 24 2026 17:37:22    (current)
  nonguix 4a8b7b0
    repository URL: https://gitlab.com/nonguix/nonguix
    branch: master
    commit: 4a8b7b082ec8f899c4b14bafa5547ea203685078
  guix 6dc8617
    repository URL: https://git.guix.gnu.org/guix.git
    branch: master
    commit: 6dc8617562efeebc1d3875f86f866a699829f65c

uname -a:
Linux guix 7.0.14 #1 SMP PREEMPT_DYNAMIC 1 x86_64 GNU/Linux

Regards,
Victor



Reply via email to