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`.
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 also required auto-fixes for Layout/EmptyLinesAroundBlockBody and
Layout/InconsistentIndentation once the auto-fixer had got rid of the
"redundant begin"s.
`-Os` produces sometimes bigger binaries on Linux.
Also, llvm built with `-Os` is really slow at runtime for Linux.
Using `-02` aligns us with what Debian does, and as we are compiling most of our stuff with gcc (and not clang), it makes sense to use `-02` on Linux.
`-Os` does probably slightly different things when used on mac with llvm, compared to when it is used with gcc on Linux.
- atomic_write: close file before renaming to prevent error:
'Device or resource busy'
- ensure_writable: preserve executable bit
- new elf? and dynamic? methods
