Conversation
|
|
Will need swiftlang/swift@e06bccd on Big Sur. Will be interesting to see how Catalina does. I might wait for Swift 5.4, since I suspect it will release very soon - very likely this coming week. It might make the Linux side of things easier. |
|
Might as well try the 5.4 snapshots and get those working rather than waste time on 5.3.3. |
c356c8e to
bab37ee
Compare
|
11.0 ARM fails on: A bit backwards? |
|
Well, that |
3e26aab to
8067310
Compare
a5797f9 to
7a6adb9
Compare
|
Nice. What're the chances your changes here would just work for swift 5.3.3? |
|
Intel: maybe if I delete a couple resources. I expect 5.4 to be released in a couple days anyway. |
|
In fact, I'll fill that time by updating this to 5.4.2 so I can see the latest logs. |
|
Building a stdlib is problematic on macOS and to be honest is probably unnecessary. Xcode toolchains no longer include it and rely on those shipped with the OS. Trying a build now without it. |
|
Ok, everything now works except arm64. I do not have an arm64 machine to properly debug this at the moment. I might borrow time from one of our CI machines or something. |
|
Here's the error log:
|
carlocab
left a comment
There was a problem hiding this comment.
I think this is good to merge, as this formula never had an ARM bottle to begin with.
Doesn't really make sense since this should be shipped by macOS in (We can build the stdlib ourselves, but there's something not right and inconsistent here.) |
|
The Swift compiler is now very particular about the target passed in, to the point where it started rejecting I checked a macOS toolchain build log for a pull of mine and the CI doesn't build TSC with CMake as you are here, even though it cross-compiles the toolchain for Mac arm64 from x86_64 in that CI run. If you're natively compiling the Swift toolchain on Mac arm64, it's possible that's not fully open-sourced by Apple yet, as with swiftlang/swift#34998. |
|
The target is correct. In fact, the triplets in The issue is one not obvious in the triplets themselves. Apple's build, although it reports itself as arm64 in the triplet, is built as arm64e. The Swift modules shipped in the SDK are also arm64e. It turns out that an arm64 build does not check for arm64e modules and so as such our build cannot find them in the SDK (and building for arm64e is not supported outside Apple). This is being fixed upstream in swiftlang/swift#39083. Applying that patch here (with a minor tweak to make it work on the 5.4 branch) fixes the problem. I also found a second, separate issue to do with triplets over in LLDB, which is invoked if you start Swift in REPL mode. It would fail to handle the arm64e CPU subtype properly and return a triplet of |
|
Is this ready @Bo98? LGTM |
|
If you're happy with how all the changes look, then I'm happy for this to be merged. I managed to make the macOS bottles relocatable which is good. Linux bottles are not yet - I'll try look into getting that sorted (if possible) before we start using it as a dependency because it's not exactly a quick thing to build. |
| resources.each do |r| | ||
| next if r.name == "six" | ||
|
|
||
| r.stage(workspace/r.name) | ||
| end |
There was a problem hiding this comment.
Since we don't use six as a resource anymore we can revert this part back (could be done later to not to retrigger the build)
| resources.each do |r| | |
| next if r.name == "six" | |
| r.stage(workspace/r.name) | |
| end | |
| resources.each { |r| r.stage(workspace/r.name) } |
There was a problem hiding this comment.
I could probably cheat and just amend the commit while merging via pr-pull.
There was a problem hiding this comment.
Bottles are 3 GB. pr-pull might take a while.
There was a problem hiding this comment.
I've dealt with LLVM back when it was all statically linked and we didn't have pr-publish, it'll probably be fine.
brew install --build-from-source <formula>, where<formula>is the name of the formula you're submitting?brew test <formula>, where<formula>is the name of the formula you're submitting?brew audit --strict <formula>(after doingbrew install <formula>)?Oh boy, it's debugging Swift time.
This contains some Linux changes which I have not tested at all yet (but will do over at linuxbrew-core).