Fixes#13762.
There's still a bug in the GCC linkage check, but I'll need a bit more
time to work on a fix. This at least makes sure `brew doctor` will not
return the error in the issue linked above.
Right now this is done through the gcc@5 formula.
See 9692318ca6/Formula/gcc%405.rb (L33)
This is fragile because when we will migrate to gcc@11
we have to think about migrating the installation from one gcc formula to another..
Also, not having the right glibc version results in a non-functional brew
installation on an older Linux: the glibc installation needs
to be done by brew, and not by a workaround in a specific formula
Co-Authored-By: Mike McQuaid <mike@mikemcquaid.com>
Co-Authored-By: Bo Anderson <mail@boanderson.me>
Co-Authored-By: Shaun Jackman <sjackman@gmail.com>
The previous implementation was depending on a fix number of version number segments. Apple has introduced one more tag for the latest CLT version 13.4, which broke the check, leading to a false warning. With this rewritten regex we have a more robust version detection.
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.
