- check the version of `/usr/bin/ld` for support of `-no_fixup_chains`
- check for usage of the `-fuse-ld` flag, since this flag is only
supported by Apple ld64
Also, call `no_fixup_chains` when setting up the build environment.
Invoking `ld` with `-undefined dynamic_lookup` emits a warning starting
Xcode 14:
ld: warning: -undefined dynamic_lookup may not work with chained fixups
Chained fixups is a linker optimisation that results in faster binary
load times, and is enabled by default starting Xcode 13 when the target
is macOS 12 or newer.
However, this interacts poorly with `-undefined dynamic_lookup`, and
Xcode will disable chained fixups when it is invoked with this flag
starting Xcode 14.3. Until then, we may be shipping binaries that are
broken in subtle ways, so let's disable chained fixups when necessary
instead.
I patterned the changes here after the handling of `-no_weak_imports`.
The only difference is that we need to check the flags that were passed
to the linker first to see if we do need to disable chained fixups.
For additional context, see:
https://developer.apple.com/documentation/xcode-release-notes/xcode-13-release-noteshttps://www.wwdcnotes.com/notes/wwdc22/110362/https://www.emergetools.com/blog/posts/iOS15LaunchTimehttps://github.com/python/cpython/issues/97524https://github.com/pybind/pybind11/pull/4301
Some formulae are able to detect the features of the runtime CPU, and
execute code accordingly. This typically entails 1) the detection of
features of the build-time CPU in order to determine the targets that
the compiler can generate code for, and 2) generating code for the
targets that the compiler can support.
Our filtering of optimization flags can cause misdetection of compiler
features, leading to failed builds [1], and miscompilation even when the
build does not fail [2].
Let's try to fix this by allowing formulae to declare
`ENV.runtime_cpu_detection` which skips the filtering of `-march` and
related flags.
I've also skipped the filtering of the optimisation
level, since it seems to me that if upstream maintainers have gone to
the lengths of writing code that detects runtime hardware, they probably
also know better about appropriate `-O` flags to use.
This is a partial list of formulae that should make use of this feature:
1. apache-arrow
2. fftw
3. gromacs
4. open-mpi
5. openblas
Partially resolvesHomebrew/homebrew-core#76537.
[1] open-mpi/ompi#8306 and linked issues/PRs
[2] Homebrew/homebrew-core#76537
The shim currently does not handle `--sysroot=` and `-isysroot=` flags
correctly. For example, the LLVM build passes `--sysroot=.`, and this is
incorrectly parsed by the shim.
Combined with https://github.com/Homebrew/homebrew-test-bot/pull/247
this will test Homebrew's use of frozen strings in CI. After this we
will then enable it for Homebrew developers and eventually all Homebrew
users.
The regular expression check for the -mmacosx-version-min value only
looked at a single digit in the minor version number, so it did not
compare correctly if the option was setting the minimum version
to (say) 10.11.
Clang has fully implemented OpenMP support as of LLVM 3.7, so if OpenMP
is required by a formula gcc is no longer the only choice of compiler.
Clang should be preferred over gcc because using gcc meant linking
against libstdc++, which is ABI incompatible with libc++. This may be
unnoticeable for some users, but it causes other builds to fail, e.g.
pstoedit when imagemagick was built with OpenMP. pstoedit is required
for the octave formula, so for some users this could be a significant
problem.
`-Wl,-z,defs` should be pruned out entirely since `-z defs` is not
understood by macOS's `ld`, and the analogue `-undefined error` is
already the default.