supranational
Compilation issues on macOS 15
Hey blst devs, apologies for the vague issue.
The Lighthouse homebrew package is struggling to build because of an issue with the -mno-avx flag on ARM64 macOS:
- https://github.com/Homebrew/homebrew-core/pull/220922
Just wondering if you've seen anything like this or might know what the issue is.
One solution would obviously be to avoid -mno-avx on ARM, but this wouldn't allow the current LH release to build (because we'd need a code change), and seems unnecessary.
No, I haven't seen anything like it, not on Github Actions (which runs macos 15 on arm) or otherwise. blst build script relies on cc-rs to filter out non-working flags, but it appears to fail to do that. -mno-avx, a non-working flag in the context, doesn't seem to bother Apple's compiler, it's a [suppressed] warming, so the question is which [C] compiler are you using. I suppose you ended up with a home-brewed one, which forcefully rejects unsuitable command-line options. Check with which clang and clang --version. If it's Apple's, then the question is what does it look like when the package is built. Try to run the build with CC environment variable set to /usr/bin/cc. Just in case, this is not to excuse cc-rs, but to resolve the presupposition.
I haven't been able to reproduce the bug locally, but will try working out which version of clang the homebrew CI is running. Thanks for the reply!
How much control over the build do you have? Or rather more specifically, can you pin cc version? The Rust crate, not the C compiler. Let's say to 1.0.106, the last one in 1.0. Again, this is not to excuse it, but to triage.
blst build script relies on cc-rs to filter out non-working flags, but it appears to fail to do that.
Hmm... It does filter out e.g. -mfoo-bar, so the question is rather why does it fail to filter out specifically -mno-avx. And apparently even more specifically fails you. The thing is that if I pick home-brewed clang on a macos/arm machine and ask cc-rs to log command lines, I see that clang is invoked without -mno-avx. And this is for the latest cc-rs version, not 1.0.106. Is it possible that the suggestion should be reversed? I.e. suppose your cc-rs version is pinned already, likely implicitly, and it happens to be a defective one. In which case the suggestion should be to unpin or re-pin it...
I've spotted cc-rs 1.2.11 in sigp/lighthouse/Cargo.lock, pinned it in my test, and can confirm that it filters out -mno-avx on a macos/arm with home-brewed clang 18.1.8...
Yeah, I have no issues building locally on my Mac. It's something specific about Homebrew's CI environment
My clang does fail if I provide -mno-avx though, i.e. this command:
env -u IPHONEOS_DEPLOYMENT_TARGET LC_ALL="C" "clang" "-O2" "-ffunction-sections" "-fdata-sections" "-fPIC" "--target=arm64-apple-macosx" "-mmacosx-version-min=15.4" "-Wall" "-Wextra" "-mno-avx" "-fno-builtin" "-Wno-unused-function" "-Wno-unused-command-line-argument" "-o" "server.o" "-c" ~/.cargo/registry/src/index.crates.io-6f17d22bba15001f/blst-0.3.13/blst/src/server.c
which is what the Homebrew server is trying to run, presumably after failing to filter -mno-avx
So the flag probe performed by cc-rs passes, but the flag is rejected the flag upon actual compilation attempt... Is there emoji for exploding head? Is it possible that the probe is performed without --target and your clang assumes x86_64 identity by default? What's clang --version output?
Just for sanity, can you confirm that the build procedure succeeds if you attempt to build as env CC=cc cargo ...
Just for sanity, can you confirm that the build procedure succeeds if you attempt to build as
env CC=cc cargo ...
Or just cargo ..., right? I mean you had to run env CC=clang cargo ... with home-brewed clang in order to trigger the problem. Or does homebrew provide cc command? If so, then double-check env CC=/usr/bin/cc cargo ....