- This was done with `brew typecheck --update --suggest-typed` which
(as of the previous commit) uses Spoom, yet another gem. I thought I'd
see how well it works. There are no Sorbet errors after these changes!
There are no more formulae in Homebrew/core that have a runtime
dependency on GCC (see Homebrew/homebrew-core#110883), so there is no
more need to retain linkage with GCC through a versioned path.
We added the `--all` flag (now renamed to `--eval-all`) for various
commands for this behaviour so let's start deprecating this.
Also, introduce a `HOMEBREW_EVAL_ALL` environment variable to use the
existing, less secure, behaviour by default and avoid passing
`--eval-all` everywhere.
- Add more early return checks
- Move to a recursive approach for more readability and avoiding a
counter that we need to bump
- Perform more caching
- Keep class variable usage isolated into specific methods
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>
There are about 10 formulae which need a bit more flexibility from
`#rpath`. Most of them use `Pathname#relative_path_from`, so we can
replace those instances with a call to `#rpath` instead once `#rpath`
knows how to handle this.
When Homebrew/homebrew-core#107517 is merged, builds will no longer be
able to find `python@3.9` as `python3`. This is also what is likely to
happen to `python@3.10` when we add a `python@3.11`.
This is likely to break many builds, so let's make sure they can keep
finding a `python3` for formulae that don't have a dependency on the
latest Python3.
This is arguably something we should've done earlier: it also means that
builds that go looking for an unversioned `python` end up finding our
Python3 (whenever present in the build environment) instead of, say,
`/usr/bin/python` which is typically Python2.
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.
