hpwooten
(Adam)
1
Hi,
I'm seeing a build failure on an Apple Silicon Mac Mini that I'm not seeing on my Intel MacBook Pro. (Both checkouts are on the same git hash)
I pulled the build command from the getting started docs and then removed --test. (I saw that as a possible solution, but unfortunately it didn't help):
utils/build-script --skip-build-benchmarks \
--skip-ios --skip-watchos --skip-tvos --swift-darwin-supported-archs "$(uname -m)" \
--sccache --release-debuginfo --swift-disable-dead-stripping \
--xcode
The build error I'm getting is:
Libtool /Users/home/Developer/swift-source/build/Xcode-RelWithDebInfoAssert/swift-macosx-x86_64/stdlib/public/LLVMSupport/Swift.build/RelWithDebInfo/swiftLLVMSupport-macosx-x86_64.build/libswiftLLVMSupport-macosx-x86_64.a normal (in target 'swiftLLVMSupport-macosx-x86_64' from project 'Swift')
cd /Users/home/Developer/swift-source/swift
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool -static -arch_only arm64 -D -syslibroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.1.sdk -L/Users/home/Developer/swift-source/build/Xcode-RelWithDebInfoAssert/swift-macosx-x86_64/stdlib/public/LLVMSupport/Swift.build/RelWithDebInfo/swiftLLVMSupport-macosx-x86_64.build -filelist /Users/home/Developer/swift-source/build/Xcode-RelWithDebInfoAssert/swift-macosx-x86_64/stdlib/public/LLVMSupport/Swift.build/RelWithDebInfo/swiftLLVMSupport-macosx-x86_64.build/Objects-normal/arm64/swiftLLVMSupport-macosx-x86_64.LinkFileList -dependency_info /Users/home/Developer/swift-source/build/Xcode-RelWithDebInfoAssert/swift-macosx-x86_64/stdlib/public/LLVMSupport/Swift.build/RelWithDebInfo/swiftLLVMSupport-macosx-x86_64.build/Objects-normal/arm64/swiftLLVMSupport-macosx-x86_64_libtool_dependency_info.dat -o /Users/home/Developer/swift-source/build/Xcode-RelWithDebInfoAssert/swift-macosx-x86_64/stdlib/public/LLVMSupport/Swift.build/RelWithDebInfo/swiftLLVMSupport-macosx-x86_64.build/libswiftLLVMSupport-macosx-x86_64.a
error: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool: no library created (no object files in input files matching -arch_only arm64)
I find it odd that it's trying to build x86_64 components. Is there something I need to add to my build command to prevent this from happening on an M1 Mac?
Here are some other stats that may be useful to know:
Xcode 12.4
macOS 11.2.1
sccache 0.2.13
cmake 3.19.1
python3 3.9.0
Thanks for the help
1 Like
Does making a --clean build helps?
If not that may be a problem on build-script
cc @typesanitizer
hpwooten
(Adam)
3
No luck with --clean unfortunately
Kelly
(Kelly O’Brien)
4
Not sure if this will solve your problem, but it resolved some of the errors I was getting on the M1. Right click on the Xcode application in your Applications folder and click 'Get Info' and check the box for 'Open using Rosetta'.
hpwooten
(Adam)
5
Same error with Xcode on rosetta
hpwooten
(Adam)
6
I've found a possible problem. Python's platform.machine() returns x86_64, and so does uname -m
1 Like
hpwooten
(Adam)
7
I think I've solved it. I was running the command under tmux, which I believe was running under rosetta. When I run those commands from the bare metal terminal, they return arm64. Starting a new build now to test
3 Likes
hpwooten
(Adam)
8
Build succeeded! Should we add a disclaimer to the getting started doc about using tools like tmux?
EDIT: This may stem from having installed homebrew before it was optimized for apple silicon. I'm troubleshooting that now
hpwooten
(Adam)
9
Yep, it was homebrew! I had installed homebrew under rosetta, so then all of its installations happened under rosetta as well.
I'm not sure this warrants any sort of documentation change, but that was a fun debug chain :)
1 Like
zoecarver
(Zoe Carver)
10
For those visiting this thread in the future:
- Make sure python is running natively.
- Make sure the terminal you're using (i.e., iTerm) isn't running via Rosetta.
6 Likes
If you want to ensure python is running natively, check that:
$ file $(which python3)
Returns arm64
2 Likes
Hello everyone!
I'm not sure if that's the ready thread to post it, but I'm having some "Unexpectedly Failures" on my lit tests after building Swift on my M1 Pro:
Running this command:
utils/build-script --skip-build-benchmarks \
--skip-ios --skip-watchos --skip-tvos --swift-darwin-supported-archs "$(uname -m)" \
--sccache --release-debuginfo --swift-disable-dead-stripping --test \
--xcode --skip-test-cmark --reconfigure --bootstrapping=off
I got this result of the following tests:
********************
Testing: 0.. 10.. 20.. 30.. 40.. 50.. 60.. 70.. 80.. 90..
4 warning(s) in tests
********************
Failed Tests (25):
Swift(macosx-arm64) :: Demangle/objc-getclass.cpp
Swift(macosx-arm64) :: Driver/LegacyDriver/legacy-driver-propagates-response-file-to-new-driver.swift
Swift(macosx-arm64) :: IRGen/conditional-dead-strip-exec.swift
Swift(macosx-arm64) :: IRGen/conditional-dead-strip-reflection.swift
Swift(macosx-arm64) :: IRGen/hermetic-seal-exec.swift
Swift(macosx-arm64) :: IRGen/prespecialized-metadata/class-class-flags-run.swift
Swift(macosx-arm64) :: IRGen/prespecialized-metadata/enum-extradata-run.swift
Swift(macosx-arm64) :: IRGen/prespecialized-metadata/enum-trailing-flags-run.swift
Swift(macosx-arm64) :: IRGen/prespecialized-metadata/struct-multi-conformance.swift
Swift(macosx-arm64) :: IRGen/prespecialized-metadata/struct-outmodule-run.swift
Swift(macosx-arm64) :: IRGen/prespecialized-metadata/struct-trailing-flags-run.swift
Swift(macosx-arm64) :: IRGen/thinlto.swift
Swift(macosx-arm64) :: IRGen/virtual-function-elimination-exec.swift
Swift(macosx-arm64) :: IRGen/virtual-function-elimination-generics-exec.swift
Swift(macosx-arm64) :: IRGen/virtual-function-elimination-two-modules.swift
Swift(macosx-arm64) :: IRGen/witness-method-elimination-exec.swift
Swift(macosx-arm64) :: IRGen/witness-method-elimination-two-modules.swift
Swift(macosx-arm64) :: Interop/SwiftToCxx/functions/cdecl.swift
Swift(macosx-arm64) :: Interop/SwiftToCxx/functions/function-availability.swift
Swift(macosx-arm64) :: Interop/SwiftToCxx/functions/swift-functions.swift
Swift(macosx-arm64) :: Interop/SwiftToCxx/module/module-to-namespace.swift
Swift(macosx-arm64) :: Interpreter/llvm_link_time_opt.swift
Swift(macosx-arm64) :: Interpreter/lto_static_lib.swift
Swift(macosx-arm64) :: PrintAsObjC/empty.swift
Swift(macosx-arm64) :: Reflection/capture_descriptors.sil
Testing Time: 414.81s
Unsupported : 521
Passed : 7909
Expectedly Failed: 26
Failed : 25
** BUILD FAILED **
The following build commands failed:
PhaseScriptExecution Generate\ test/CMakeFiles/check-swift-macosx-arm64 /Users/robertorosmaninho/swift-project/build/Xcode-RelWithDebInfoAssert/swift-macosx-arm64/test/Swift.build/RelWithDebInfo/check-swift-macosx-arm64.build/Script-8049DAF62D42E741FF678E47.sh (in target 'check-swift-macosx-arm64' from project 'Swift')
(1 failure)
ERROR: command terminated with a non-zero exit status 65, aborting
Before that, I had a problem with CMark tests, which I "solved" with -skip-test-cmark, but I reported here, and also I have the following problem:
The following build commands failed: Ld /Users/robertorosmaninho/swift-project/build/Xcode-RelWithDebInfoAssert/swift-macosx-arm64/bootstrapping1/RelWithDebInfo/bin/swift-frontend normal (in target 'swift-frontend-bootstrapping1' from project 'Swift') (1 failure)
Which I "solved" using --reconfigure --bootstrapping=off.
For instance, python3 is running natively and I'm using MacOS 12.3 with XCode version 13.3.0.0.1.1645755326
My main question here is if those errors are something that I have to be worried about before starting contributing to the C++ Interop Group. What do you think, @zoecarver?
I can provide more info about those failures if needed! :)
The problem is with --test I think, you could try to build removing --test because that will just build the compiler and not run the tests against Xcode build. It is common for people to run two builds one Xcode(used for development and debugging) and one ninja build to run the tests. This comes with a little disk space impact but normally not a big hit.
For example, the workflow I normally have is to build with Xcode using ./swift/utils/build-script --xcode --debug --debug-swift --skip-build-benchmarks --swift-darwin-supported-archs "$(uname -m)" --sccache --skip-ios --skip-tvos --skip-watchos --bootstrapping=off to devopment and debugging.
Then have a ninja build using:
./swift/utils/build-script --release --skip-build-benchmarks --swift-darwin-supported-archs "$(uname -m)" --sccache --skip-ios --skip-tvos --skip-watchos that we can run after making changes and locally run all lit tests against ninja build using:
llvm-project/llvm/utils/lit/lit.py -sv --param swift_site_config=build/Ninja-ReleaseAssert/swift-macosx-arm64/test-macosx-arm64/lit.site.cfg swift/test/
This helps not having to run --test with Xcode build which is normally not as stable as ninja
So with that said I'd recommend give it a try without --test. I hope that helps =]
2 Likes
Yes, that solved the problem for me and with Ninja worked just fine!
I'm newer with the Swift environment, so this tip about your workflow is very valuable for me! Thank you for your help and attention with this. I'll follow this from now on!
1 Like