Having log files with extensions like `.cc` and `.cmake` is really
unfriendly to editor syntax highlighters and language servers. Let's try
to make sure these are opened as log files by adding a `.log` extension
to them.
Our parsing of linker flags can be easily confused by, e.g.,
-Wl,-undefined -Wl,dynamic_lookup,-dead_strip_dylibs
The current code that tries to detect these flags will erroneously
conclude that they were not passed.
This change fixes that.
A local `ruby` build failed while building extensions, with:
*** Following extensions are not compiled:
-test-/file:
Could not be configured. It will not be installed.
/tmp/ruby-20240824-893184-ehcnsa/ruby-3.3.4/lib/mkmf.rb:480: The compiler failed to generate an executable file.
You have to install development tools first.
Check ext/-test-/file/mkmf.log for more details.
-test-/symbol:
Could not be configured. It will not be installed.
/tmp/ruby-20240824-893184-ehcnsa/ruby-3.3.4/lib/mkmf.rb:480: The compiler failed to generate an executable file.
You have to install development tools first.
Check ext/-test-/symbol/mkmf.log for more details.
[...]
`mkmf.log` indicated that the compiler shim failed to load `pathname`:
LD_LIBRARY_PATH=.:../../.. "gcc-13 -o conftest -I../../../.ext/include/aarch64-linux -I../../.././include -I../../.././ext/-test-/file -I/home/linuxbrew/.linuxbrew/opt/libyaml/include -I/home/linuxbrew/.linuxbrew/opt/openssl@3/include -O3 -fno-fast-math -ggdb3 -Wall -Wextra -Wdeprecated-declarations -Wdiv-by-zero -Wduplicated-cond -Wimplicit-function-declaration -Wimplicit-int -Wpointer-arith -Wwrite-strings -Wold-style-definition -Wimplicit-fallthrough=0 -Wmissing-noreturn -Wno-cast-function-type -Wno-constant-logical-operand -Wno-long-long -Wno-missing-field-initializers -Wno-overlength-strings -Wno-packed-bitfield-compat -Wno-parentheses-equality -Wno-self-assign -Wno-tautological-compare -Wno-unused-parameter -Wno-unused-value -Wsuggest-attribute=format -Wsuggest-attribute=noreturn -Wunused-variable -Wmisleading-indentation -Wundef -fPIC conftest.c -L. -L../../.. -L/home/linuxbrew/.linuxbrew/opt/libyaml/lib -Wl,-rpath,/home/linuxbrew/.linuxbrew/opt/libyaml/lib -L/home/linuxbrew/.linuxbrew/opt/openssl@3/lib -Wl,-rpath,/home/linuxbrew/.linuxbrew/opt/openssl@3/lib -L. -fstack-protector-strong -L/home/linuxbrew/.linuxbrew/opt/libyaml/lib -Wl,-rpath,/home/linuxbrew/.linuxbrew/opt/libyaml/lib -L/home/linuxbrew/.linuxbrew/opt/openssl@3/lib -Wl,-rpath,/home/linuxbrew/.linuxbrew/opt/openssl@3/lib -rdynamic -Wl,-export-dynamic -Wl,--no-as-needed -Wl,-rpath,/home/linuxbrew/.linuxbrew/Cellar/ruby/3.3.4/lib -L/home/linuxbrew/.linuxbrew/Cellar/ruby/3.3.4/lib -lruby-static -lz -lrt -lrt -ldl -lcrypt -lm -lpthread -lm -lpthread -lc"
/home/linuxbrew/.linuxbrew/Homebrew/Library/Homebrew/shims/linux/super/gcc-13:12:in `require': cannot load such file -- pathname (LoadError)
from /home/linuxbrew/.linuxbrew/Homebrew/Library/Homebrew/shims/linux/super/gcc-13:12:in `<main>'
I believe this was due to `../../..` in `LD_LIBRARY_PATH` containing
`libruby.so`, causing the Ruby script to load the being-built Ruby
library instead of the system/portable one.
- 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.
