Hi, yes. The toolchain is just the compiler and related build tools and the Android SDK is the stdlib, Foundation etc.
The toolchain is the linux one from our swift CI server (flowkey). (As a side note it’d be great if you could fix this capitalisation @compnerd. It’s flowkey, not FlowKey, same as it’s not faceBook). And the Android SDK comes from the Windows builds as you saw. It’s the only Android SDK being built there, last I checked. But you could use any SDK because the build target (Android) is the deciding factor, not where it’s built.
Oh, I'm sorry, I didn't realize that. You should have mentioned it earlier! Either way, fixed in the status and the Azure build name. If I have accidentally missed any location, please let me know and I'm happy to fix that.
No worries :) I had fixed it myself at some point but the error crept back in so I thought I should mention it. Sorry, this isn’t the best space for that kind of discussion; will get in touch in person next time! Thanks for updating it
Correcting us here is just fine. I had noticed the discrepancy but assumed that the “flowkey” on your website was just the result of a lowercase font. I would have continued perpetuating the mistake too if you hadn’t commented here.
I just successfully built the same “Hello, world!” library with the toolchain and SDK downloaded directly from Azure. I guess that means the problem with the docker image is due to something that was temporarily broken at the time the docker image was assembled? The commit that introduced @_implicitly_synthesizes_nested_requirement is from December 9. Does that hypothesis make sense to you, @compnerd?
I guess building a library is a far cry from linking it into an executable. I managed to eventually figure out some --sysroot weirdness. But now I’m stuck with this:
ld.lld: error: unable to find library -lgcc
ld.lld: error: unable to find library -lgcc
clang: error: linker command failed with exit code 1 (use -v to see invocation)
<unknown>:0: error: link command failed with exit code 1 (use -v to see invocation)
The Android NDK download does not contain a libgcc.a under platforms/anrdoid‐*/arch-*/usr/lib. Am I supposed to hunt down the file somewhere and tell Swift where it is? Am I supposed to tell Swift it shouldn’t try to link that? Either way, how?
(@v.gorlov, did you hit this too after you got past “cannot open crtbegin_dynamic.o”?)
Yes, you do need to hunt down some flags for that. Alternatively, you should look at the build configuration for Azure at GitHub - compnerd/swift-build: Alternate Swift Builds (yes, I know, I sound like a broken record).
should do the trick (assuming Windows -> ARM64). You would need to adjust the windows to linux if you are using Linux. If you are compiling to some other architecture, adjusting the arm64 will be needed.
Believe it or not, that has been my go‐to since the first time you said that. I just don’t always understand what I’m looking at, and other times get unlucky with my search strategies. This time I ran a search for -L and checked each hit for paths that might be related to libgcc, yielding nothing useful. Had I searched for gcc instead I’d have found --gcc-toolchain immediately, but the possibility of a separate flag hadn’t occurred to me until I saw your explanation.
While applying the Windows script to actual projects, I’m having to disable a lot of tests with #if !os(Windows), because they crash with “Exception: SegFault”. Is that likely to be a fault of my set‐up, or a bug in Swift?
None of the code is memory related, and nothing is using Unsafe symbols; the simplest such test merely calls -= on an Int by way of a protocol.
Unfortunately, thats not sufficiently detailed to help isolate what may be going on. Int and -= is not only used heavily in the standard library but in Foundation as well. I think that there may be something else going on thats far more subtle. I've had a number of projects build just fine on Windows (e.g. YAMS, tools-support-core, swift-package-manager, XCTest, Foundation, PythonKit, TensorFlow). I'd be surprised if there is something wrong in Int. Can you reduce the failure down to something standalone?
Yup. And it’s been annoying me for the five days I’ve spent trying to narrow the issue down. It will take a while yet.
For now I’m just asking in general if you have ever seen Windows’ “SegFault” message from omitting a library, linking the wrong architecture, or something that might actually be my fault. “SegFault” sounds to me like the compiler has bungled something, but I thought I may as well ask someone more familiar with Windows and its error messages.
There are far too many things for it to be, a segmentation fault alone doesn't indicate anything other than an invalid memory access. It could even be a latent use-after-free that would even trigger on Darwin. Without a stack trace and a reduced test case, its hard to guess. Normally, my approach here would be to try to reconstruct the stack manually and then try to isolate what may be happening.
I just filed SR‐12123 because SwiftPM’s AST wrapping step does not pass any of the -X or --destination information to swiftc, resulting in the module wrapper being created for the wrong toolchain, platform and architecture. (CC: @Aciid)
Right now it can be worked around by sticking to --configuration release, because the AST wrapping is only applied for the debug configuration.
In release mode I now have it linking an Android executable with no complaints. (Though I haven’t tried launching the executable yet to know if it actually worked.)
SEGFAULTs rate on Windows hit a significant growth about 2 weeks ago. Looks like it related to CF->NS bridging. I am expecting more info about this soon.
I am so close to getting Android tests working. I have it cross‐compiling to Android x86 with SwiftPM on an Ubuntu host, and then being passed to a macOS host where it is placed in a running Android Emulator, and then the WhateverPackageTests.xctest executable is being launched. It can link libswiftCore.so, libXCTest.so and the others from the Swift SDK as long as I copy them into the same directory as the executable.
But now it is complaining about libc++_shared.so, which originates from the Android NDK:
WARNING: linker: Warning: unable to normalize "D"
CANNOT LINK EXECUTABLE "/data/local/tmp/[...]PackageTests.xctest": library "libc++_shared.so" not found
I have copied it into the same directory and ls clearly verifies its presence there. Does anyone have any ideas about why the dynamic linker cannot find what is right in front of it? Or even why it is needed? I am not knowingly using any C++.
(I was about to try inspecting the executable with otool -L when the build suddenly failed with...
<unknown>:0: error: compiled module was created by an older version of the compiler; rebuild 'Swift' and try again: /Library/Developer/Platforms/Android.platform/Developer/SDKs/Android.sdk/usr/lib/swift/android/i686/Swift.swiftmodule
...which I assume means nothing will work anyway until at least the next nightly.)
I can branch this out into another thread if that's better, but is the current status of SPM for Windows documented anywhere? I'd be interested in helping to fix any remaining issues with that - I see there are a bunch of PRs open for Windows that seem to be stuck at the moment.
Since the artifacts received by swift-build.py don’t work at the moment, I tried Azure’s GUI again, to find that it works now. I downloaded older artifacts manually and uploaded them to a GitHub release so I could keep experimenting. I guessed wrong and got another incompatible pair, but it did reduce the per‐job download time from 10 minutes to 10 seconds. This whole process would have gone a lot faster if I had realized that sooner.
I also came across this post, which might explain where the need for the C++ standard library comes from. Once I get it compiling again I will try inspecting the linkage of libswiftCore.so.
