ruby-macho chokes on changing duplicate RPATHs, so we need to strip the
duplicates before trying to relocate them.
This continues #11405. We need this to unblock
Homebrew/homebrew-core#91224.
While we're here, let's get rid of `HOMEBREW_RELOCATE_RPATHS`. We've
been using it for nearly a year with essentially no problems (barring
`pdnsrec`), so I think it is safe to do unconditionally.
Upon reflection, I realised that this is probably a bug in `ruby-macho`,
and should be fixed there instead.
Needs https://github.com/Homebrew/ruby-macho/pull/362.
This reverts commit e8b5eb7e42c925b7cc10c78a029b8c70e4d7965b.
One of the more curious bugs, if you use
-Wl,-headerpad_max_install_names on linux, it tries to link a library
named "eaderpath_max_install_names" in, which causes all kinds of weird
havoc.
Most notably, gtester inside glib fails to run for bizarre reasons.
-Wl,-headerpad_max_install_names is not an option anywhere outside macos
anyway, so move it to macos only and avoid the heartache of extremely
weild bugs.
Java-dependent formulae produce different bottles on macOS and Linux
because they have different values for `JAVA_HOME` (`opt_libexec` vs
`opt_libexec/"openjdk.jdk/Contents/Home"`).
Let's handle this difference by using the placeholder
`@@HOMEBREW_JAVA@@` in a bottle, like so:
#!/bin/bash
JAVA_HOME="${JAVA_HOME:-@@HOMEBREW_JAVA@@}" exec "@@HOMEBREW_CELLAR@@/clojure/1.10.3.998/libexec/bin/clojure" "$@"
Currently, this says something like
Ruby version 2.6.8 is unsupported on 12.
which is a little cryptic. Let's change that to say
Ruby version 2.6.8 is unsupported on macOS 12.
There are at least five instances where a formula has libraries compiled
with `-flat_namespace` due to a bug in detecting the macOS version (cf.
Homebrew/homebrew-core#87103, Homebrew/homebrew-core#85974,
Homebrew/homebrew-core#85973).
I think it makes sense to check for this more generally. It is
sometimes intentional, so I've added a check for an allowlist for
those instances. Running this on the current `util-linux` bottle
produces
❯ brew audit --strict util-linux
util-linux:
* Libraries were compiled with a flat namespace.
This can cause linker errors due to name collisions, and
is often due to a bug in detecting the macOS version.
/usr/local/Cellar/util-linux/2.37.2/lib/libblkid.1.dylib
/usr/local/Cellar/util-linux/2.37.2/lib/libfdisk.1.dylib
/usr/local/Cellar/util-linux/2.37.2/lib/libsmartcols.1.dylib
/usr/local/Cellar/util-linux/2.37.2/lib/libuuid.1.dylib
Error: 1 problem in 1 formula detected
Some things that still need to be done here:
- fix this check for universal binaries
- check if we want to restrict this audit check to newer versions of macOS
- fix false positives (try `brew audit --strict llvm` and compare the
output of `otool -hV` on the identified files)
While we're here, let's fix the formatting of the output of these other
audits (cf. #12217).
- Only for HOMEBREW_DEVELOPER
- Except for HOMEBREW_CORE_MERGE_MAINTAINER
- Except for GitHub Actions CI
Co-authored-by: Rylan Polster <rslpolster@gmail.com>
Co-authored-by: Mike McQuaid <mike@mikemcquaid.com>
If you have Homebrew LLVM installed, `brew config` will show
Clang: 12.0.1 build (parse error)
because Homebrew LLVM does not give a build number. Some installations
from the system package manager do have this information, so let's show
it if it's available but skip complaining if not.
I've kept the original code for macOS because we always expect Apple's
build number to show there.
Bison no longer remembers the path to `m4` as of
Homebrew/homebrew-core#84931. Since superenv does not put runtime
dependencies of build dependences in `PATH`, we now need to help Bison
find `m4` by setting `M4` in the environment.
See also Homebrew/homebrew-core#85260.
