I have done my armhf-linux swift toolchain and building doc.
You can find here:
https://forums.swift.org/t/introducing-my-armhf-swift-5-9-toolchiain/69524/3
1 Like
@CmST0us thanks for all this hard work. I saw your repo and reproduced the results locally, and got Swift 5.9 working on my Raspberry Pi 4 running Ubuntu 22.04 armhf. I was even able to copy over some of your stuff to @ColemanCDA's swift-armv7 repo and got it to build as well for our armv7 platform (based on an Atmel SAMA5, no neon instructions, etc).
So, I guess our next steps are figuring out how to create a build on the community CI for all this. @Finagolfin and @kubamracek I am willing to put this together since I was able to get it working. How do I get started creating a build on the CI server?
3 Likes
There are two different CI options and you've now referenced both of them in this thread, so I'm unsure which one you have in mind. The first is easy and mentioned at the end of the CI page: a "community" CI you host yourself. The second is an official CI hosted by Apple, and adding your platform to this page. That requires core team approval, which I thought you were discussing with them a couple months ago.
In either case, rather than running a CI on a weak 32-bit board, my suggestion is to rent out an AArch64 server, install the 32-bit armv7 environment available in many linux distros, and run the armv7 test suite in AArch32 mode on that 64-bit CPU.
2 Likes
Thank you for putting this together @CmST0us! It's great that we have an up-to-date Swift 5.9 version now for armv7 and hopefully it will be easy to update it to Swift 5.10 and main as well.
@mishal_shah: When we talked earlier, I understood that you could possibly help out here and set something up. Either a full official CI (eventually), or perhaps something that may not be fully there yet, but is at least a starting point that we can improve upon. The current status is that it compiles (and runs), but there are no tests executed. In what state do you need this to be in order to start setting something up? Would a CI set-up that just builds the runtime/stdlib, without executing any tests, be acceptable as a starting point for the time being? Or should we first make the test suite execute properly? If you think it's too early and we should start out with a community CI, then we could have a look at that as well.
@xtremekforever: There are still a couple of patches required to make this build work. I guess one of the first things we could have a look at is creating proper fixes for these and upstream them. At least the patches to make the Ubuntu build run properly, and I think we could also have a look at improving the situation for selecting a specific processor and FPU, like we need for our Cortex-A5 build.
Sorry about the confusion there. When you sent me the official Swift CI repo I mistook it for the community CI, and with me not knowing the setup of things it didn't click that it was the official CI. So, my goal is to start with a community CI to find the issues and work out the kinks, and then once everything is in place start pull requesting to Apple to see if we can add an official CI.
It would be nice to be able to rent some powerful AArch64 hardware. Would you happen to know where that would be available?
@orobio of course, we need to look at those patches and make sure they'll work across the board. Let me know if there's anything I can do to help with that.
I have never rented out such an AArch64 server myself, but here are some well-known options that I've heard of: Hetzner, Equinix, AWS EC2, and Azure.
1 Like
Well I've been working towards getting Swift to build for Debian 11 Bullseye and finally got a cross toolchain together with Swift 5.10. However, I am very unclear about the next steps towards setting up a community CI. @Finagolfin you sent me the link from Apple on how to do this but I did not understand. Is this something you have experience with?
Either way, if it's been quiet from me, it's because I'm not sure how to proceed, although I would love to figure out how to get something setup. And I am able to build Swift 5.10 with just a few patches applied to @ColemanCDA's swift-armv7 scripts. I just don't know how to get all this into a "CI" per se...
Could you share your patches? I'd like to update my build scripts for 5.10
1 Like
The first step would be to run the compiler validation suite and see how many tests fail. The Android community CI runs the armv7 tests in --host-test mode, ie skipping the tests that require running cross-compiled executables, so you can look at that build preset it invokes to see how to do something similar for your linux armv7 CI.
Once you have it passing enough tests, you can follow the process in the README, or contact @mishal_shah about adding it to the official CI.
1 Like
I sent you a pull request with all I did to get a Swift 5.10 cross toolchain working. Unfortunately it's not the full SDK but that would require more work and patches.
@Finagolfin thanks for the info. I shall try this and hopefully get some results soon when I get a chance to work on it! Right now with @ColemanCDA's scripts a build preset is not being used, but I think it could be easy enough to create one and also probably something that will be needed for an official CI. But for now, I have a next step. Thanks again!
Thanks, I just got 5.10 building today for Buildroot Armv7, so Debian shouldn't be far away.
1 Like
I got Swift 5.10 cross compiling for Bookworm armhf
2 Likes
@ColemanCDA Thank you so much for your work setting up these toolchain scripts. I noticed in the 0.6.0 release the swift-armv7 artifact is pretty slim, and doesn't have any of the swift-front end binaries that previous releases had (like 0.5.1). Is this intended?
Yes, for Swift 5.10 I am not able to compile the full tool set, just the runtime.
2 Likes
So: update on my efforts. It has become clear that it will be difficult to support armv7 officially within the swiftlang/swift toolchain. And, the only way that makes sense to support it is to build the runtime for the target, then cross-compile from x86_64 or aarch64 to armv7. So, I've launched my effort for this:
Moving forward, this can just be a small community CI and we (as the community) can keep the effort alive of supporting armv7 for future releases.
4 Likes
Got a better idea: the new official Android CI is the first public CI that runs most of the compiler validation suite, excluding the 5% of executable tests that require running on the target architecture, for a 32-bit architecture, Android armv7, and requires passing, which excludes the Wasm CI, which only runs around 15-20% of that large compiler test suite, and the internal 32-bit watchOS CI, which doesn't appear to be public (the Windows toolchain CI used to run the Android compiler validation suite for 32-bit arches, but never required those tests to pass and now appears to have stopped running them too).
@mishal_shah and @kubamracek, what do you think about adding the Android CI as a requirement for compiler pulls on the main branch in the github UI, primarily to make sure most of the compiler tests pass for a 32-bit architecture? I am not worried about 64-bit Android, which we can always fix tests for as issues arise, but in the couple weeks since the official Android CI has been going, it has proven to be a good canary for compiler tests that don't pass for 32-bit arches.
I primarily think this would be good for the embedded work that is ongoing, which I understand mostly targets 32-bit arches these days, not because of Android armv7 itself, which is not a particularly important target anymore.
2 Likes
Windows does have the 32-bit CPU support and that is widely used. Are there Android specific bits that are the concern or ARMv7 specific? The 32-bit support on Windows is x86 only as the WoA chips are no longer being supported by Microsoft and they have started investing in removing the support for WoA from their toolchains. WoS is the primary ARM usage on Windows now, but that is a 64-bit environment.
I'm sure it is, but I don't see the compiler validation suite run for 32-bit Windows x86 on the official CI, as I detailed above for other 32-bit arches.
Neither, my concern is only for making sure that most of the compiler validation suite is run for any 32-bit arch before new compiler pulls are merged. Currently, new pulls are merged, then we wait to see if the 32-bit watchOS or Android armv7 test runs fail later, and try to fix them.
I am only suggesting that we be more proactive with some 32-bit arch that's all, could be any one.
Right, I didn't mean to imply that it was currently covered.
Likewise - I'm simply suggesting that this might be an easier thing to accomplish and perhaps easier to run. That is, I'm simply pointing out an alternative approach which might hopefully be less time consuming on the CI runs (if it is more time consuming, we should not go down this path).
I don't think 32-bit Android is likely to end up as one of the mandatory CI platforms, so we'd still be waiting for other bots to run.
1 Like