This adds GCC's runtime lib directory to the RPATH of every build on
Linux (unconditionally!).
This is useful for three things:
1. It fixes versioned GCC linkage for formulae that users build from
source instead of pouring from a bottle. We currently only handle
bottle installs. See #13633.
2. It helps minimise the GCC dependency explosion. When a formula has a
Linux-only GCC dependency, then all its dependents that link with
some GCC runtime library (typically `libstdc++`) must, before this
change, also adopt a GCC dependency. This is a consequence of our
injecting GCC's runtime library directory into RPATH only when a
formula is built with GCC (this is done through the specs file). We
can avoid the need to do this by always injecting this path instead.
3. This enables us to automatically install Homebrew GCC whenever the
user's GCC is too old and the formula may need it. Without this
change, auto-installing GCC is not that useful because formulae that
need it may not know to look for our GCC, unless the formula already
happened to be built with our GCC. With this change, these formulae
will always be able to find our GCC when it is installed. This is
particularly useful for when we start building with a version of GCC
that is much closer to the latest than we currently do.
This approach comes with at least two drawbacks:
1. We will see spurious linkage warnings in CI about an undeclared
dependency with linkage as soon as Homebrew GCC is installed, because
formulae will link with our GCC instead of the host's. Users will
also see a similar complaint if they do `brew linkage`.
2. This leans _very_ heavily on GCC delivering backward compatibility of
their runtime libraries. If they do not, we could see different
behaviour across different CI runs for the same formula depending on
whether Homebrew GCC is installed.
It's worth noting that item 3 in the "useful" list above may rely on
features not yet implement in `brew`.
This complements my other two GCC-on-Linux PRs (#13631, #13633), however
they are both reliant on bottles eventually being (re-)poured.
Let's try to speed that up by returning an error message from `brew doctor`
whenever a user has formulae installed that would benefit from a `brew reinstall`.
This should help keep bottles that require GCC working when
Homebrew/homebrew-core#106755 is merged.
This only works on freshly-poured bottles. Previously installed bottles
will still break on systems with a host GCC older than GCC 11.
- 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>
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.
This method takes an optional array of `Pathnames`s or `Strings`s and
extracts the native slice from the specified universal binary. If no
parameter is supplied, this is done on all compatible universal binaries
in a formula's keg.
`deuniversalize_machos` is a no-op on Linux.
I still need to look into a) error handling, and b) whether using this
method requires codesigning on ARM.
I've also added signatures to the methods in `extend/os/linux/formula`.
About 40 formulae set `CMAKE_INSTALL_RPATH` to `lib` or `opt_lib`, but
this breaks bottle relocatability.
The correct solution is to use `@loader_path/../lib`, but this is macOS
specific, so it requires some OS-specific logic. Rather than replicating
this logic over many formulae, we may as well define a helper method for
it.
See https://github.com/Homebrew/homebrew-core/issues/75458.
