[LLVM on Mojave] ld: unknown option: -platform_version
banach-space opened this issue · 30 comments
Please note we will close your issue without comment if you delete, do not read or do not fill out the issue checklist below and provide ALL the requested information. If you repeatedly fail to use the issue template, we will block you from ever submitting issues to Homebrew again.
- ran
brew updateand can still reproduce the problem? - ran
brew doctor, fixed all issues and can still reproduce the problem? - ran
brew gist-logs <formula>(where<formula>is the name of the formula that failed) and included the output link? - if
brew gist-logsdidn't work: ranbrew configandbrew doctorand included their output with your issue?
What you were trying to do (and why)
I want to use LLVM-10 on MacOS Mojave. I have been able to install it successfully, but the clang binary is broken.
What happened (include command output)
This is how I've tried to use clang-10 after installing it with brew:
Command output
/usr/local/opt/llvm/bin/clang-10 -isysroot `xcrun --show-sdk-path` file.c ld: unknown option: -platform_version clang-10: error: linker command failed with exit code 1 (use -v to see invocation)
Running clang with -v reveals this:
ld: unknown option: -platform_version
What you expected to happen
clang-10 not to use the -platform_version flag when running on Mac OS Mojave (the flag is not supported by the linker available there).
The relevant LLVM issue is available here: https://bugs.llvm.org/show_bug.cgi?id=44813. This has been fixed here: https://reviews.llvm.org/D74784, i.e. the fix is available in LLVM-10.
AFAIK, this does not affect Mac OS Catalina on which the linker does support -platform_version.
Step-by-step reproduction instructions (by running brew install commands)
After installing LLVM-10 with brew install:
/usr/local/opt/llvm/bin/clang-10 -isysroot `xcrun --show-sdk-path` file.c
Mac OS Mojave (the flag is not supported by the linker available there).
It is on my Mojave install. Can I see a brew config?
And a brew doctor too
brew config:
$ brew config
HOMEBREW_VERSION: 2.2.11
ORIGIN: https://github.com/Homebrew/brew
HEAD: fa8fe0fc396550c23156043cd07550fc6ae6a27a
Last commit: 9 days ago
Core tap ORIGIN: https://github.com/Homebrew/homebrew-core
Core tap HEAD: c974d3d6af4665c86ae1f2c11a1d728fde89f8d5
Core tap last commit: 2 hours ago
HOMEBREW_PREFIX: /usr/local
CPU: octa-core 64-bit kabylake
Homebrew Ruby: 2.6.3 => /usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.3/bin/ruby
Clang: 10.0 build 1001
Git: 2.26.0 => /usr/local/bin/git
Curl: 7.54.0 => /usr/bin/curl
macOS: 10.14.6-x86_64
CLT: 10.3.0.0.1.1562985497
Xcode: 11.3.1
brew doctor:
$ brew doctor
Please note that these warnings are just used to help the Homebrew maintainers
with debugging if you file an issue. If everything you use Homebrew for is
working fine: please don't worry or file an issue; just ignore this. Thanks!
Warning: Unbrewed header files were found in /usr/local/include.
If you didn't put them there on purpose they could cause problems when
building Homebrew formulae, and may need to be deleted.
Unexpected header files:
/usr/local/include/python2.7/greenlet/greenlet.h
/usr/local/include/python3.7m/greenlet/greenlet.h
Warning: You have unlinked kegs in your Cellar.
Leaving kegs unlinked can lead to build-trouble and cause brews that depend on
those kegs to fail to run properly once built. Run `brew link` on these:
python@2
cmake
Warning: Homebrew's sbin was not found in your PATH but you have installed
formulae that put executables in /usr/local/sbin.
Consider setting the PATH for example like so:
echo 'export PATH="/usr/local/sbin:$PATH"' >> ~/.bash_profile
Can I also get the output of ld -v?
Also:
ld -v
@(#)PROGRAM:ld PROJECT:ld64-450.3
BUILD 18:16:53 Apr 5 2019
configured to support archs: armv6 armv7 armv7s arm64 arm64e arm64_32 i386 x86_64 x86_64h armv6m armv7k armv7m armv7em
LTO support using: LLVM version 10.0.1, (clang-1001.0.46.4) (static support for 22, runtime is 22)
TAPI support using: Apple TAPI version 10.0.1 (tapi-1001.0.4.1)
Apologies for using my other account earlier - that's just unnecessary confusion on my side.
Ok, so for you it is using ld from the CLT rather than the newer one in Xcode. That's the difference I think between our setups.
It's likely that the CI built the Mojave bottle using a newer ld. Unless overridden by /usr/local/opt/llvm/bin/clang-10 -mlinker-version=450.3 ..., it will take the linker version Clang was built with - which is 530.
I can maybe get Clang built on the older linker. I'm not sure though if that would cause further problems when using newer linkers.
Thanks a ton for looking into this!
I've built LLVM-10 manually following the steps from this formula [1] and clang works just fine (to be more precise, I used the formula to make sure that I use the same sources).
IIUC, wIth the fix [2] already included in clang, the version of the system linker shouldn't matter. I did step through my local debug build and clang indeed verifies that my linker is a bit older (i.e. <520) and doesn't add -platform_version.
One thing that would be really worth verifying is the version of the sources used to build the binaries. Maybe for whatever reason one of RCs was used that didn't contain the fix?
[1] https://github.com/Homebrew/homebrew-core/blob/master/Formula/llvm.rb
[2] https://reviews.llvm.org/D74784
The default value of -mlinker-version is determined here:
https://github.com/llvm/llvm-project/blob/llvmorg-10.0.0/clang/lib/Driver/Driver.cpp#L400-L409
It defaults to HOST_LINK_VERSION which is baked in at compile time of clang:
https://github.com/llvm/llvm-project/blob/llvmorg-10.0.0/clang/CMakeLists.txt#L388-L406
Our bottles are built with the latest linker available on Mojave, which is 530. Hence, -mlinker-version will default to 530. ld -v is not considered at runtime.
It might be worth pointing out that there's a workaround: clang -mlinker-version=450 (450 is the linker version discovered with ld -v).
clang -mlinker-version=0 will also work, but in this case clang will drop even more flags.
I have the same issue with clang 10, and I also have ld version 450, probably b/c I have installed only the CLT, not XCode. Is there a way to upgrade ld without installing xcode?
Is there a way to upgrade ld without installing xcode?
Yes, it involves installing CLT 11.3 (the latest version that is supported on Mojave) manually from the Apple's website (xcode-select --install only offers an outdated 10.3).
However, if you do this you must delete the older CLT first or you will get a corrupted install.
rm -rf /Library/Developer/CommandLineTools
Nice. Thanks for the quick reply, that worked.
Do we expect this will get fixed soon (tm) with apple offering CLT 11.3 via softwareupdate?
Could homebrew check / error when the bottle is installed while ld is not the latest?
Apple are unlikely to ever offer 11.3 on Mojave softwareupdate. They did not do so for 11.0-11.2. They've moved on to 11.4 already - which is Catalina only. So Mojave softwareupdate will probably remain stuck on 10.3.
I'll have a think what the best approach here is for Mojave. I could potentially use a older linker for creating the bottle.
So CLT 11.3 actually caused some problems b/c AppleClang 11 somehow behaves differently to AppleClang 10 w.r.t. the library features it thinks are available, even if you use the same libc++ from homebrew (llvm version 10). There is a difference for C++17 features that werent available in AppleClang 10, but in 11, like full std::filesystem support, and the CLT upgrade broke our builds.
Ok, so for you it is using ld from the CLT rather than the newer one in Xcode. That's the difference I think between our setups.
I'm trying to understand in which cases you get the newer linker version > 450 on Mojave. So I first thought from the comment above it is different if I install Xcode. But after installing Xcode 10.3 (which is maybe the latest version you get via softwareupdate?), it's still the same linker version 450. In retrospect that makes sense of course. I just thought Apple might be handing out more recent updates for XCode and not CLT.
So when you say the newer one in Xcode above, you mean XCode 11.3, which you also have to download manually?
I'm trying to understand which AppleClang version people working on Mojave would typically have (also to decide which combination of OS and compiler we should support/test in our own projects). Looks like it should in general be version 10, independent from whether they get it with CLT or XCode, right?
Downloading 11.3 from the apple website is maybe more of an exotic setup (both XCode or CLT)? In that case all Mojave bottles should maybe in general be built with XCode 10.3, no?
PS: Interestingly, brew thinks my xcode is outdated and suggests to update it from the softwareupdate, even though that doesn't work:
$ brew reinstall llvm -s
==> Reinstalling llvm
Warning: Your Xcode (10.3) is outdated.
Please update to Xcode 11.3.1 (or delete it).
Xcode can be updated from the App Store.
[...]
While CLT 10.3 is the latest in softwareupdate, Xcode 11.3 is the latest on the App Store. On a fresh Mojave install, if you download Xcode you get 11.3. Older versions require manual install.
So CLT 11.3 actually caused some problems b/c AppleClang 11 somehow behaves differently to AppleClang 10 w.r.t. the library features it thinks are available
Ultimately I don’t know how you are doing the feature detection, but if you are using the latest SDK, you are likely using the Catalina SDK (added in 11.x) which will have filesystem headers but they are marked as Catalina only and will refuse compile on older systems. This is how macOS SDKs work.
I appreciate your continued comments! The below is a bit OT for homebrew, but in general I think it's also relevant how homebrew should deal with the possibility for different compiler versions on different Mojave machines.
Maybe installing through AppStore changed with Xcode version 11.4, which is not compatible with Mojave. When I tried to install XCode yesterday from the app store, it tells me that it's not compatible:
I then installed xcode 10.3 by manual download and xcode-select. Software-update doesn't offer anything apart from the OS-Catalina update. My macOS version is 10.14.6. I specifically don't want to upgrade b/c this is a ci-build machine that is supposed to test mojave.
So that means that on Mojave, depending on whether people installed CLT or XCode, and also when they installed XCode, they will be stuck with either AppleClang 10 or 11, even if they always get the latest from softwareupdate. So if we want to support devs on Mojave, we'd have to either tell them to manually download CLT/XCode 11.3 if they are stuck on 10 and then support only 11, or we'd have to support both 10 and 11.
Ultimately I don’t know how you are doing the feature detection, but if you are using the latest SDK, you are likely using the Catalina SDK (added in 11.x) which will have filesystem headers but they are marked as Catalina only and will refuse compile on older systems. This is how macOS SDKs work.
Yes, maybe we are doing things not properly here. We are using Cmake and not doing anything special to select the SDK. But we actually just tried setting CMAKE_OSX_DEPLOYMENT_TARGET to 10.15, to compile on Mojave with CLT 11.3, and that worked for using std::filesystem, and the executables also run 😲. But I'm not what bits are actually part of the "macos SDK" that are OS version specific. We don't use any native macos GUI stuff or something, just via thirdparty libraries. Our own code is cross platform linux / mavos.
When I say "the executables also run", it's true that we so far only tested the command line executables, unit tests etc...
Yes, Xcode 11.4 is Catalina only. 11.3.1 is the last on Mojave. The App Store should offer only 11.3.1 on Mojave but I think it doesn't really work correctly all the time and still offers 11.4 (probably intentional to try and get people to upgrade to Catalina). If I remember correctly, it should work correctly on new installs.
The Mojave situation is indeed a bit annoying with the CLT stuck on 10.3 and Xcode being on 11.3.1. From a Homebrew perspective, we support both.
Back on the topic of LLVM, I'll try tweak the formula this weekend to see if I can get it working on CLT 10.3.
For the sake of others that might want to workaround this issue in the meantime and cannot for some reason install CLT / Xcode 11.3:
I can report that as expected, you can install / downgrade to Xcode 10.3 and compile llvm yourself with brew reinstall llvm -s to have clang work with ld version 450. Note that you need Xcode to compile llvm, CLT is not enough.
Apologies if this is irrelevant but I've just run into a similar issue trying to build a Python C extension.
Mac OS: Mojave 10.14.6.
xcode-select -v -> 2354.
XCode About box: Version 11.3.1 (11C504)
ld -v:
@(#)PROGRAM:ld PROJECT:ld64-450.3
BUILD 18:16:53 Apr 5 2019
configured to support archs: armv6 armv7 armv7s arm64 arm64e arm64_32 i386 x86_64 x86_64h armv6m armv7k armv7m armv7em
LTO support using: LLVM version 10.0.1, (clang-1001.0.46.4) (static support for 22, runtime is 22)
TAPI support using: Apple TAPI version 10.0.1 (tapi-1001.0.4.1)
I'm using: https://bitbucket.org/mrabarnett/mrab-regex/src/hg/
This project contains a small C extension so is a good example, but from looking at the setup.py it would happen for any standard Python C extension build. Checking out that code and building the extension:
git clone https://bitbucket.org/mrabarnett/mrab-regex.git
cd mrab-regex
python3 setup.py build_extfails with:
clang -bundle -undefined dynamic_lookup -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk build/temp.macosx-10.14-x86_64-3.7/regex_3/_regex.o build/temp.macosx-10.14-x86_64-3.7/regex_3/_regex_unicode.o -L/usr/local/lib -L/usr/local/opt/openssl@1.1/lib -L/usr/local/opt/sqlite/lib -o build/lib.macosx-10.14-x86_64-3.7/regex/_regex.cpython-37m-darwin.so
ld: unknown option: -platform_version
clang-10: error: linker command failed with exit code 1 (use -v to see invocation)
error: command 'clang' failed with exit status 1
As a trial and error experiment I switched XCode to "Full XCode" (I'm not sure what the pertinent distinction is between CommandLIne XCode and Full XCode):
sudo xcode-select -s /Applications/Xcode.app/Contents/Developerld -v is now:
@(#)PROGRAM:ld PROJECT:ld64-530
BUILD 18:57:17 Dec 13 2019
configured to support archs: armv6 armv7 armv7s arm64 arm64e arm64_32 i386 x86_64 x86_64h armv6m armv7k armv7m armv7em
LTO support using: LLVM version 11.0.0, (clang-1100.0.33.17) (static support for 23, runtime is 23)
TAPI support using: Apple TAPI version 11.0.0 (tapi-1100.0.11)
Rerunning python3 setup.py build_ext now succeeds.
Note to get back to command line XCode run:
sudo xcode-select --switch /Library/Developer/CommandLineToolsHope that helps.
mac os x 10.9
brew config
HOMEBREW_VERSION: 2.2.14
ORIGIN: https://github.com/Homebrew/brew
HEAD: e2bc0fa
Last commit: 29 hours ago
Core tap ORIGIN: https://github.com/Homebrew/homebrew-core
Core tap HEAD: 142161a
Core tap last commit: 2 hours ago
HOMEBREW_PREFIX: /usr/local
HOMEBREW_DISPLAY: /tmp/launch-PHZfjm/org.macosforge.xquartz:0
HOMEBREW_MAKE_JOBS: 4
CPU: quad-core 64-bit haswell
Homebrew Ruby: 2.6.3 => /usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.3/bin/ruby
Clang: 6.0 build 600
Git: 2.26.2 => /usr/local/opt/git/bin/git
Curl: 7.69.1 => /usr/local/opt/curl/bin/curl
Java: 1.6.0_65-b14-462
macOS: 10.9.5-x86_64
CLT: 6.2.0.0.1.1424975374
Xcode: 6.2
XQuartz: 2.7.11 => /opt/X11
brew install llvm
.....
make: *** [all] Error 2
Do not report this issue to Homebrew/brew or Homebrew/core!
These open issues may also help:
[LLVM on Mojave] ld: unknown option: -platform_version #52461
@1371030 That doesn't have anything to do with this issue which is about the linker on Mojave.
You've snipped the logs (and haven't provided a brew gist-logs llvm) so I can't possibly tell what the issue is. It's very possible that LLVM 10 is not supported on 10.9 and you may need an older version, like llvm@9 or earlier.
Either way, it does say:
Do not report this issue to Homebrew/brew or Homebrew/core!
So asking on the forum will be your best bet.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.
I guess the issue remains relevant. It will likely only go away by itself once Mojave is EOL, which is still maybe 1.5 years out. So I guess it depends on how much time @Bo98 (or someone else) has to spend on a fix.
The workaround to manually build llvm from source is workable, albeit it takes some time.
Not sure what the policy here is regarding stale issues, but seems like they wanna close open issues, even if confirmed, unless someone steps up to fix it within a few weeks.
Does sudo xcode-select -s /Applications/Xcode.app/Contents/Developer on Mojave 10.14.6 work ?
What do you mean work? To fix the ld: unknown option: -platform_version error? I guess it depends on which version of XCode is installed. If it's 11.3, the I guess yes.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.