Several bottles resulting in "segmentation fault" on Red Hat Enterprise Linux release 8.6

[jwhite007]

brew gist-logs <formula> link OR brew config AND brew doctor output

$ brew config
HOMEBREW_VERSION: 3.6.12-20-g9c88c39
ORIGIN: https://github.com/Homebrew/brew
HEAD: 9c88c39baead6bbc40b12ab1eae9b63bcb5a8042
Last commit: 4 days ago
Core tap ORIGIN: https://github.com/Homebrew/homebrew-core
Core tap HEAD: 2a1eae1579c3885c1d832fac4a5af864bb8e204b
Core tap last commit: 7 minutes ago
Core tap branch: master
HOMEBREW_PREFIX: /home/linuxbrew/.linuxbrew
HOMEBREW_CASK_OPTS: []
HOMEBREW_EDITOR: /usr/bin/env vim
HOMEBREW_GITHUB_API_TOKEN: set
HOMEBREW_LOGS: /home/linuxbrew/.logs/Homebrew
HOMEBREW_MAKE_JOBS: 48
HOMEBREW_NO_CLEANUP_FORMULAE: autoconf,berkeley-db,binutils,bzip2,ca-certificates,expat,gcc,gdbm,glibc,gmp,isl,libffi,libmpc,libxcrypt,[email protected],lz4,m4,mpfr,ncurses,[email protected],perl,pkg-config,pyenv,readline,xz,zlib,zstd
HOMEBREW_TEMP: /home/linuxbrew/.temp
Homebrew Ruby: 2.6.8 => /home/linuxbrew/.linuxbrew/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.8_1/bin/ruby
CPU: 48-core 64-bit broadwell
Clang: N/A
Git: 2.38.1 => /home/linuxbrew/.linuxbrew/bin/git
Curl: 7.61.1 => /bin/curl
Kernel: Linux 4.18.0-372.26.1.el8_6.x86_64 x86_64 GNU/Linux
OS: Red Hat Enterprise Linux release 8.6 (Ootpa) (Ootpa)
Host glibc: 2.28
/usr/bin/gcc: 8.5.0
/usr/bin/ruby: N/A
glibc: 2.35_1
gcc@11: N/A
gcc: 12.2.0
xorg: N/A

$ brew dr
Please note that these warnings are just used to help the Homebrew maintainers
with debugging if you file an issue. If everything you use Homebrew for is
working fine: please don't worry or file an issue; just ignore this. Thanks!

Warning: "config" scripts exist outside your system or Homebrew directories.
`./configure` scripts often look for *-config scripts to determine if
software packages are installed, and which additional flags to use when
compiling and linking.

Having additional scripts in your path can confuse software installed via
Homebrew if the config script overrides a system or Homebrew-provided
script of the same name. We found the following "config" scripts:
  /toolbox/bioinformatics/.pyenv/shims/python3.9-config
  /toolbox/bioinformatics/.pyenv/shims/python-config
  /toolbox/bioinformatics/.pyenv/shims/ncursesw6-config
  /toolbox/bioinformatics/.pyenv/shims/ncurses6-config
  /toolbox/bioinformatics/.pyenv/shims/python3-config
  /toolbox/bioinformatics/.pyenv/shims/icu-config

Warning: Some taps are not on the default git origin branch and may not receive
updates. If this is a surprise to you, check out the default branch with:
  git -C $(brew --repo bioinformatics_group/local-pyenv) checkout

### Verification

- [X] I ran `brew update` and am still able to reproduce my issue.
- [X] I have resolved all warnings from `brew doctor` and that did not fix my problem.

### What were you trying to do (and why)?

Run several applications installed from bottles.

### What happened (include all command output)?

$ R
Segmentation fault

$ ccat \<some file\>.txt
Segmentation fault

$ ll | awk '{print $1}'
Segmentation fault

Seems like all of the applications installed with util-linux are also resulting in segmentation faults, applications such as more, rev, etc.

### What did you expect to happen?

A clean run with no segmentation fault.

### Step-by-step reproduction instructions (by running `brew` commands)

```shell
Same as in "What happened" section.

[Bo98]

I've seen some reports of this on WSL (for gcc-12 at least: #115895) but have so far not managed to reproduce.

I can't reproduce this in a centos:8 Docker container - it works fine when I try.

[SMillerDev]

Cantos 8 isn't really RHEL, or supported. I'd recommend Alma Linux 8 or Rocky 8

[Bo98]

Seems fine on AlmaLinux 8 at least:

# more --version
more from util-linux 2.38.1

I do recognise there is likely a problem somewhere. Though there seems to be a step to reproduce that's not obvious and not something I'm hitting on fresh installations.

[jwhite007]

I'm not sure if the following helps or not. I thought I might try to zero in on if the segmentation faults were coming from a common dependency; however, the deps of curl include all those of ccat, and the former works just fine. Both curl and ccat were poured from bottles on my system.

[jwhite007]

I thought that since I was having problems with the bottles, I'd go ahead and explore building some of these from source. At least two of these, R and util-linux, are failing during the build with statements such as the following.

checking for gcc... gcc
checking whether the C compiler works... no
configure: error: C compiler cannot create executables
See `config.log' for more details

[Bo98]

I thought that since I was having problems with the bottles, I'd go ahead and explore building some of these from source. At least two of these, R and util-linux, are failing during the build with statements such as the following.

checking for gcc... gcc
checking whether the C compiler works... no
configure: error: C compiler cannot create executables
See `config.log' for more details

Yeah you might be hitting segfaults when running gcc-12 too - worth checking.

[jwhite007]

@Bo98,

Exactly as you guessed.

$ gcc-12 --version
Segmentation fault

Luckily we keep snapshots, and I was able to rollback to a Linuxbrew image where most bottles were working well. This will be temporary, of course.

[Bo98]

Does running a broken binary with LD_DEBUG=all point to anything?

[jwhite007]

@Bo98

No debug output.

$ LD_DEBUG=all more test.txt
Segmentation fault

[Bo98]

Can you try debuginfo-install glibc, run a bad binary through gdb and let me know what it crashes on?

[jwhite007]

@Bo98

Unfortunately I do not have root on these systems. Root seems to be required by debuginfo-install glibc

UPDATE: gdb was already on the system.

$ gdb -q /home/linuxbrew/.linuxbrew/Cellar/util-linux/2.38.1/bin/more

Reading symbols from /home/linuxbrew/.linuxbrew/Cellar/util-linux/2.38.1/bin/more...(no debugging symbols found)...done.

[Bo98]

Can you upload that bad binary so I can compare with what I have?

[jwhite007]

@Bo98

Github doesn't allow direct uploads of binaries, so I've wrapped it in a zip.

more.zip

[dbroadfoot]

Hi,

I'm trying to run brew on Redhat 8, hitting the exact same problem for a week or so (it was working before). Segfaults in gcc, binutils etc. I do have root access...anything I can do to help? Any updates?

[jwhite007]

As I mentioned earlier, I've rolled back to a snapshot version of brew. That is version 3.6.11-5-g06b7573. I'm not getting seg faults with the bottles in this version.

[jwhite007]

Curiously the versions of at least two of the applications that lead to seg faults are the same as before the seg faults started happening.

more from util-linux 2.38.1
ccat 1.1.0

And the only differences between each of the respective latest and former formulas is the addition of the sha256 hash of the ventura versions in the latest.

The seg faults seem to be coming from some common dependency; however, brew deps ccat returns nothing. I'd think brew deps ccat --include-build would be irrelevant as this is a bottle issue.

[jwhite007]

Another curious thing is that I get a bit different behavior on another machine with the same Homebrew version; although, I have less applications installed to it. The following is the config for what I will call Machine2, Machine1 having the config which I initially posted. The only major difference that I can see is that the linux kernels are different, but only minorly.

$ brew config
HOMEBREW_VERSION: 3.6.12-20-g9c88c39
ORIGIN: https://github.com/Homebrew/brew
HEAD: 9c88c39baead6bbc40b12ab1eae9b63bcb5a8042
Last commit: 9 days ago
Core tap ORIGIN: https://github.com/Homebrew/homebrew-core
Core tap HEAD: 45201431913da5d2085fa3ab660c8f9e6ca23c5a
Core tap last commit: 7 days ago
Core tap branch: master
HOMEBREW_PREFIX: /home/linuxbrew/.linuxbrew
HOMEBREW_CASK_OPTS: []
HOMEBREW_EDITOR: /usr/bin/env vim
HOMEBREW_GITHUB_API_TOKEN: set
HOMEBREW_LOGS: /home/linuxbrew/.logs/Homebrew
HOMEBREW_MAKE_JOBS: 4
HOMEBREW_NO_CLEANUP_FORMULAE: autoconf,berkeley-db,binutils,bzip2,ca-certificates,expat,gcc,gdbm,glibc,gmp,isl,libffi,libmpc,libxcrypt,[email protected],lz4,m4,mpfr,ncurses,[email protected],perl,pkg-config,pyenv,readline,xz,zlib,zstd
HOMEBREW_TEMP: /home/linuxbrew/.temp
Homebrew Ruby: 2.6.8 => /home/linuxbrew/.linuxbrew/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.8_1/bin/ruby
CPU: quad-core 64-bit skylake
Clang: N/A
Git: 2.38.1 => /home/linuxbrew/.linuxbrew/bin/git
Curl: 7.61.1 => /bin/curl
Kernel: Linux 4.18.0-372.32.1.el8_6.x86_64 x86_64 GNU/Linux
OS: Red Hat Enterprise Linux release 8.6 (Ootpa) (Ootpa)
Host glibc: 2.28
/usr/bin/gcc: 8.5.0
/usr/bin/ruby: N/A
glibc: 2.35_1
gcc@11: 11.3.0
gcc: 12.2.0
xorg: N/A

The curious behavior:
Machine1:

$ ls .linuxbrew/Cellar/gcc/
12.2.0

$ gcc-12 --version
Segmentation fault

$ ls .linuxbrew/Cellar/ccat/
1.1.0

$ ccat --version
Segmentation fault

$ ls .linuxbrew/Cellar/util-linux/
2.38.1

$ more --version
Segmentation fault

Machine2:

$ ls .linuxbrew/Cellar/gcc/
12.2.0

$ gcc-12 --version
Segmentation fault

$ ls .linuxbrew/Cellar/ccat/
1.1.0

$ ccat --version
ccat v1.1.0

$ ls .linuxbrew/Cellar/util-linux/
2.38.1

$ more --version
more from util-linux 2.38.1

[jwhite007]

@dbroadfoot,

Would you please post your output of both brew config and brew dr? Thanks.

[jwhite007]

I don't know enough about the more binary to know if the following is a valid test. I've copied the broken version from Machine1 to Machine2 (where the Linuxbrew-installed more works).

The following was done on Machine2. Machine2 version below is the one in the Linuxbrew path.

$ /home/linuxbrew/.linuxbrew/Cellar/util-linux/2.38.1/bin/more --version
more from util-linux 2.38.1

$ ./more --version
Segmentation fault

$ cmp /home/linuxbrew/.linuxbrew/Cellar/util-linux/2.38.1/bin/more ./more
/home/linuxbrew/.linuxbrew/Cellar/util-linux/2.38.1/bin/more ./more differ: byte 57, line 1

Alternatively, if I copy the functional more binary from Machine2 to Machine1 and test there, it works:

$ ./more --version
more from util-linux 2.38.1

Same behavior with ccat.

$ cmp /home/linuxbrew/.linuxbrew/Cellar/ccat/1.1.0/bin/ccat ./ccat
/home/linuxbrew/.linuxbrew/Cellar/ccat/1.1.0/bin/ccat ./ccat differ: byte 130, line 1

[Bo98]

I can't reproduce in the RHEL UBI 8 Docker image, so I'm guessing this is something lower level (e.g. kernel). WSL2 had similar issues but it seems like the latest version fixed them (with newer kernel etc.).

I'll try set up a full VM and see if I can hit the issue in that.

[Bo98]

Another curious thing is that I get a bit different behavior on another machine with the same Homebrew version; although, I have less applications installed to it. The following is the config for what I will call Machine2, Machine1 having the config which I initially posted. The only major difference that I can see is that the linux kernels are different, but only minorly.

Can you also upload the working binary so I can compare?

Might also be worth comparing installation dates ("Poured from bottle" date in brew info util-linux)

[dbroadfoot]

[kls@rhlibpubwdev01 ~]$ brew config
HOMEBREW_VERSION: 3.6.13
ORIGIN: https://github.com/Homebrew/brew
HEAD: 7478293
Last commit: 6 days ago
Core tap ORIGIN: https://github.com/Homebrew/homebrew-core
Core tap HEAD: dec8479
Core tap last commit: 4 days ago
Core tap branch: master
HOMEBREW_PREFIX: /home/linuxbrew/.linuxbrew
HOMEBREW_CASK_OPTS: []
HOMEBREW_MAKE_JOBS: 4
Homebrew Ruby: 2.6.8 => /home/linuxbrew/.linuxbrew/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.8_1/bin/ruby
CPU: quad-core 64-bit ivybridge
Clang: N/A
Git: 2.27.0 => /bin/git
Curl: 7.61.1 => /bin/curl
Kernel: Linux 4.18.0-348.23.1.el8_5.x86_64 x86_64 GNU/Linux
OS: Red Hat Enterprise Linux release 8.5 (Ootpa) (Ootpa)
Host glibc: 2.28
/usr/bin/gcc: 8.5.0
/usr/bin/ruby: N/A
glibc: 2.35_1
gcc@11: N/A
gcc: 12.2.0
xorg: N/A

[kls@rhlibpubwdev01 ~]$ brew dr
Your system is ready to brew.

[jwhite007]

@Bo98 ,

I really appreciate your time on this. I know that the Homebrew maintainers do so on a volunteer basis. This issue is not super critical to me as I state above that I was able to rollback to a functional version of which I'd taken a snapshot; however, I'd like to be able to have a functional up-to-date Homebrew at some point in the near future. Please let me know if there is anything else that I can do to help.

I'm not sure how we'll discern anything from when the bottles were poured. Aren't those times kind of arbitrary? Wouldn't the Homebrew versions which I've posted above be more relevant? Anyhow, I'm posting the pour times as you requested. I'm also attaching the zipped functional more from util-linux on Machine2.

Pour times:
Machine1 (dysfunctional more): Poured from bottle on 2022-11-26 at 12:39:03
Machine2 (functional more): Poured from bottle on 2022-09-03 at 11:09:52

machine2_more.zip

[Bo98]

I'm not sure how we'll discern anything from when the bottles were poured. Aren't those times kind of arbitrary? Wouldn't the Homebrew versions which I've posted above be more relevant? Anyhow, I'm posting the pour times as you requested. I'm also attaching the zipped functional more from util-linux on Machine2.

The version of patchelf used changed in that timeframe. I'm guessing we're patching something about the ELFs in a way that only breaks on very specific Linux distributions.

[dbroadfoot]

@Bo98 ,

my situation is more urgent...currently trying to provision 3 new servers using Brew via a script. I developed script, all worked, now I'm trying to use it in anger on 3 'clean' servers and it fails.

Is there anything I can do to expedite this issue?

Is there some way I can roll brew back to a version that works?

Also this may or may not be relevant, but when I was trying to find a workaround and build some packages from source, I would occasionally run into an ELF bug...I suspected this might be in play

https://bugzilla.redhat.com/show_bug.cgi?id=1678204

For what its worth, i was able to download gcc, for example, from git repo, and compile / build manually without brew...that worked. But trying to to install with brew --build-from-source did not.

[jonchang]

We can't really help on an urgent basis. One thing to possibly try to is to try with old versions of patchelf.rb (and disable Homebrew from requiring the newest version of such by e.g. setting the versioned directories appropriately appropriately). If this works then we know it's a patchelf/patchelf.rb bug

[dbroadfoot]

I have the following

./Homebrew/Library/Homebrew/vendor/bundle/ruby/2.6.0/gems/patchelf-1.4.0/lib/patchelf.rb
./Homebrew/Library/Homebrew/vendor/bundle/ruby/2.6.0/gems/patchelf-1.4.0/bin/patchelf.rb
./Homebrew/Library/Homebrew/vendor/bundle/ruby/2.6.0/bin/patchelf.rb
./Homebrew/Library/Taps/homebrew/homebrew-core/Formula/patchelf.rb

I do have an install on a machine from October that works...which files should I replace and what do you mean exactly by 'setting the versioned directories appropriately' ?

[jonchang]

I don't know what files would need to be replaced, since I can't reproduce this issue. You would have to do this experimentation on your own.

[dbroadfoot]

as a sanity check tried to reproduce on a freshly spun up EC2 running Red Hat Enterprise Linux 8 image

cat /etc/redhat-release
Red Hat Enterprise Linux release 8.6 (Ootpa)

I did

sudo yum install git
sudo yum groupinstall 'Development Tools'

made sure my ec2 user had access to /home/linuxbrew/

installed brew
brew install gcc

go the exact same error as I've been getting on my other server:

==> Pouring gcc--12.2.0.x86_64_linux.bottle.2.tar.gz
Warning: The post-install step did not complete successfully
You can try again using:
brew postinstall gcc

and gcc-12 and other gcc binaries just segfault with all efforts to use them

tried

brew install gcc --build-from-source --debug -v

error is

gcc: internal compiler error: Segmentation fault signal terminated program as
Please submit a full bug report,
with preprocessed source if appropriate.
See http://bugzilla.redhat.com/bugzilla for instructions.
configure:4510: $? = 4
configure:4548: result: no
configure: failed program was:
| /* confdefs.h /
| #define PACKAGE_NAME ""
| #define PACKAGE_TARNAME ""
| #define PACKAGE_VERSION ""
| #define PACKAGE_STRING ""
| #define PACKAGE_BUGREPORT ""
| #define PACKAGE_URL ""
| / end confdefs.h. */
|
| int
| main ()
| {
|
| ;
| return 0;
| }

[gromgit]

@jwhite007, maybe try git -C $(brew --repo) revert 031bd9cd18c41867104a2a0b405d090c3028d1cf, since that's the commit that upgraded patchelf from 1.3.0 to 1.4.0.

[dbroadfoot]

Bingo!

Thanks you @gromgit !!

did

git revert 031bd9c
HOMEBREW_NO_AUTO_UPDATE=1 brew install gcc

and now gcc-12 etc all work without seg fault!

How long before there's a fix for this and I don't have to disable auto update??

[SMillerDev]

I don't know how long it'll take until someone who has this issue contacts the patchelf developers, works with them to find and resolve the bug, and for the patchelf developers to release that fix.

[Bo98]

I'm looking into it as soon as I can. Hardware issues mean I don't have access to my usual setup, but I'm looking at WSL1 to see what the issues are there which might be liked to this one.

I don't know if a fix will be released by Christmas but I'm hoping a possible fix will be identified by then. The issues seem to affect very specific setups, particularly given the issues on the WSL side were fixed recently by Microsoft.

Note that the older patchelf does have issues that are more widespread, like qt installs being broken. It'll still be a better situation for your particular case though.

[jwhite007]

@gromgit,

Thanks. However, you probably meant to address @dbroadfoot in your comment above. I had rolled back to a functional Linuxbrew from a snapshot I had taken.

[jwhite007]

@Bo98,

As I stated, I was able to get a functional Linuxbrew from a snapshot that I had, and it seems that @dbroadfoot was able to revert to a commit with a functional Linuxbrew, so I think we're both probably good for the next several weeks. Please enjoy the holidays and don't feel as if you guys need to fix anything before Christmas or the New Year even. I'm most appreciative that Linuxbrew is even a thing.

Again, if there is anything else with which I can assist in the matter, please let me know.

[jwhite007]

@dbroadfoot ,

I'm not sure if the setup we use will work with your particular framework; however, our production-based stuff is only dependent on one particular tool installed with Linuxbrew, and that is pyenv. We install pyenv via Linuxbrew and then miniconda via pyenv. We then have all of our production pipelines working within locked-down, stable Conda environments. Back in Linuxbrew, I extract all Formulas for pyenv and all of its dependencies. Then when I go to upgrade via Linuxbrew or install something to Linuxbrew that might upgrade one of pyenv's dependencies, I first upgrade anything pyenv related and check for pyenv functionality before proceeding. In this way, even though a lot of applications in Linuxbrew were seg faulting in this latest update, I had ensured that pyenv was still solid, thus ensuring that all of our production code was still functional.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[jwhite007]

Commenting to keep issue active.

[SMillerDev]

There's no need to keep it active for the bot if nobody is doing anything with it.

[jwhite007]

@SMillerDev, I thought that this was still being worked on. The bot marked it as stale and then subsequently closed as "not planned." Shall we assume that Linuxbrew will not support RHEL going forward? Thanks.

[SMillerDev]

Since it doesn't affect all RHEL systems, that seems a bit premature. But seeing how it does seem to affect your configuration that assumption probably puts you on the safer side of this problem.

[jwhite007]

@SMillerDev,

So from here on out, determining whether Linuxbrew will support a particular Linux will just be hit or miss? I mean we really don't know why my configuration and that of @dbroadfoot are not working. Right? It's also curious that Linuxbrew had been working just fine for almost a year on my configuration. I guess I'd really like to figure out exactly what it is about our configurations that are screwing things up. Any idea on how I would go about determining that? Is it the version of RHEL? Is it the version of the Linux kernel?

[SMillerDev]

#116841 (comment) suggests it's a bug in patchelf, but without anyone pursuing that I guess we'll never know.

[Bo98]

As an update: I've identified a possible issue, but haven't actually managed to reproduce the issue yet to test though. I'll update back here again next week.

[gromgit]

@Bo98, let me know if I can help with reproduction or testing on a different architecture (ARM Linux) that also went pear-shaped after the patchelf 1.4.0 upgrade. I suddenly saw the following error when using previously-built relocatable ARM Linux bottles:

==> Pouring libaec-1.0.6.aarch64_linux.bottle.tar.gz
tar --extract --no-same-owner --file /home/aho/.cache/Homebrew/downloads/fce2e5d2ea3d8e8ac20c99f98b2b1a54fb74c7819e37280a903156d60f35e5c1--libaec-1.0.6.aarch64_linux.bottle.tar.gz --directory /home/linuxbrew/.linuxbrew/tmp/d20230117-4134160-159mmfb
cp -pR /home/linuxbrew/.linuxbrew/tmp/d20230117-4134160-159mmfb/libaec/. /home/linuxbrew/.linuxbrew/Cellar/libaec
Error: cannot normalize PT_NOTE segment: non-contiguous SHT_NOTE sections

so I had to rebuild all my bottles with --skip-relocation going forward.

[indigoviolet]

Just chiming in that I'm seeing a lot of the same issues:

❯ brew config 
HOMEBREW_VERSION: 3.6.20
ORIGIN: https://github.com/Homebrew/brew
HEAD: 344d32bf7f40183359592ef81ca6486e0587981b
Last commit: 12 days ago
Core tap ORIGIN: https://github.com/Homebrew/homebrew-core
Core tap HEAD: 8fbf4bc9e970403ae365d7bf99a2cc5ee9813159
Core tap last commit: 4 hours ago
Core tap branch: master
HOMEBREW_PREFIX: /home/linuxbrew/.linuxbrew
HOMEBREW_CASK_OPTS: []
HOMEBREW_EDITOR: micro
HOMEBREW_MAKE_JOBS: 12
HOMEBREW_NO_AUTO_UPDATE: set
HOMEBREW_NO_INSTALL_CLEANUP: set
Homebrew Ruby: 2.6.8 => /home/linuxbrew/.linuxbrew/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.8_
1/bin/ruby
CPU: dodeca-core 64-bit haswell
Clang: 7.0.1 build 701
Git: 2.20.1 => /bin/git
Curl: 7.64.0 => /bin/curl
Kernel: Linux 4.19.0-23-cloud-amd64 x86_64 GNU/Linux
OS: Debian GNU/Linux 10 (buster) (buster)
Host glibc: 2.28
/usr/bin/gcc: 8.3.0
/usr/bin/ruby: 2.5.5
glibc: 2.35_1
gcc@11: N/A
gcc: 12.2.0
xorg: N/A

The revert from #116841 (comment) didn't work for me -- I probably didn't resolve the conflict correctly;

I instead did git reset --hard a7c5e40c1 and fixed my broken installs by reinstalling.

[jwhite007]

It appears that there has been some work in fixing a related bug in patchelf, NixOS/patchelf#447. According to that pull request, 0.17.2 has been released to address the related bug. Does anyone know if this latest version of patchelf is now being used for Linuxbrew bottles?

[gromgit]

Nope. Homebrew uses a different pure-Ruby patchelf implementation: https://github.com/david942j/patchelf.rb

[Bo98]

For me this is a post-4.0.0 priority: so next week. I've got this, WSL1 and upx noted to investigate.