We were rewriting dylib IDs and install names using `MachO::Tools`,
which doesn't update the state of the file in memory. This leads to
those changes being undone when we call `delete_rpath`.
We fix this by making sure the state of the file in memory always
matches the state of file on disk.
Closes#12832.
It's possible that the output may be encoded ASCII-8BIT, which cannot be automatically encoded to UTF-8 by Ruby's JSON library.
In this particular case, elementaryOS 6.1 returns `Jólnir` as a part of the lsb_release Description field.
Ruby's IO.popen would return this whole output in ASCII-8BIT.
When this description field was passed to homebrew-bundle to be written in a JSON lockfile,
Ruby throws an exception because it could not automatically reencode from ASCII-8BIT to UTF-8.
This may actually affect other output of the calls to the underlying `Utils.popen_read` but this may be the first thing to trigger it since
JSON requires UTF-8 output and nothing else using that function may require UTF-8.
Fixes#12689 12689
FixesHomebrew/homebrew-bundle#1043
An executable that links against @rpath-prefixed dylibs must include at least
one runtime path. This will prevent issues like the one resolved in #91485.
Caveats:
1. This won't find executables that have only recursive dylib dependencies with
@rpath prefixes.
2. This makes no attempt to resolve @rpath, @executable_path or @loader_path
dylibs, or to verify the correctness of any LC_RPATH entries, or to
otherwise simulate dlopen logic.
3. Weakly-linked dylibs are still excluded from the search for broken linkage.
The scope is narrow in order to focus on this particular problem. It is meant
only as a sanity check.
There have been a few instances I've noticed that we've been silently
installing binaries built for x86_64 on ARM. There's probably more that
I haven't found yet, so it seems useful to check this with an audit.
