armhf support

[lhoward]

How difficult would it be to add armhf target architecture support (for Linux)?

[MaxDesiatov]

This would definitely require a Swift toolchain build, which I'm actually interested in supporting in the generator eventually.

Are you targeting a specific Linux distribution? Would you be able to clarify what that is and its exact version for development and testing?

[lhoward]

I'm building on Ubuntu 22.04.3 aarch64-linux-gnu and would like to target the same distribution, but on arm-linux-gnueabihf. (I'm working on an embedded product and I'm keen to see if I can save a bit on BOM costs but using a 32-bit CPU. I imagine I'll use Yocto or something similar for the final product.)

[xtremekforever]

I'm also interested in this but have been unable to build a full toolchain for Swift for armhf. We have been able to build llvm, swift, and the core libraries for armhf to be able to put together a simple sysroot for Debian 11 and 12, but beyond that that we don't have any other tools built.

I wonder how much of a toolchain we actually need to support armhf/armv7 as a cross-compilation target with this SDK generator? @MaxDesiatov do you know what we'd need?

[MaxDesiatov]

Do you have a preset for that platform defined in the presets file? https://github.com/swiftlang/swift/blob/main/utils/build-presets.ini

Core libraries should be enough in theory, and if those can be built with a readily available preset, it would simplify the generator setup a lot.

[xtremekforever]

I don't have anything in build-presents.ini, instead we've been using cmake due to the fact that it's actually possible to cross compile for armv7 without too much pain. Is it even possible to cross compile using buildbot? If not then that takes it away as an option...

[MaxDesiatov]

Everything buildable with a preset locally can be built with a buildbot too, I'm not aware of any differences between those two cases that would preclude cross-compilation.

[xtremekforever]

In my experience using build presets with buildbot to try to cross compile armv7 is a pain. There's always an issue of LLVM not finding something, some path being wrong, or it straight up doing a step that doesn't work for cross compilation. I will continue looking at it, but I wonder if the generator would work if I just pointed it to some artifacts that were built with cmake that are for armv7...which would include Swift stdlib, dispatch, foundation, and xctest.

[xtremekforever]

@MaxDesiatov I have a buildbot profile that can generate the Swift stdlib and corelibs (dispatch, foundation, xctest) for armv7 that can be used for cross-compilation. It does require a separate armhf sysroot of Ubuntu/Debian (possibly even Fedora) but this can be used on a CI system as well. I am working on creating a pull request to swiftlang/swift with these changes, but I still wonder how having this would help to create an SDK generator for it?

Here are the directories that are generated from the buildbot in <install_destdir>/usr/lib/swift/linux:

├── armv7
│   ├── glibc.modulemap
│   ├── SwiftGlibc.h
│   └── swiftrt.o
├── _Concurrency.swiftmodule
│   ├── armv7-unknown-linux-gnueabihf.abi.json
│   ├── armv7-unknown-linux-gnueabihf.private.swiftinterface
│   ├── armv7-unknown-linux-gnueabihf.swiftdoc
│   ├── armv7-unknown-linux-gnueabihf.swiftinterface
│   └── armv7-unknown-linux-gnueabihf.swiftmodule
├── CxxStdlib.swiftmodule
│   ├── armv7-unknown-linux-gnueabihf.private.swiftinterface
│   ├── armv7-unknown-linux-gnueabihf.swiftdoc
│   ├── armv7-unknown-linux-gnueabihf.swiftinterface
│   └── armv7-unknown-linux-gnueabihf.swiftmodule
├── Cxx.swiftmodule
│   ├── armv7-unknown-linux-gnueabihf.private.swiftinterface
│   ├── armv7-unknown-linux-gnueabihf.swiftdoc
│   ├── armv7-unknown-linux-gnueabihf.swiftinterface
│   └── armv7-unknown-linux-gnueabihf.swiftmodule
├── Glibc.swiftmodule
│   ├── armv7-unknown-linux-gnueabihf.abi.json
│   ├── armv7-unknown-linux-gnueabihf.private.swiftinterface
│   ├── armv7-unknown-linux-gnueabihf.swiftdoc
│   ├── armv7-unknown-linux-gnueabihf.swiftinterface
│   └── armv7-unknown-linux-gnueabihf.swiftmodule
├── libBlocksRuntime.so
├── libcxxshim.h
├── libcxxshim.modulemap
├── libcxxstdlibshim.h
├── libdispatch.so
├── libFoundationNetworking.so
├── libFoundation.so
├── libFoundationXML.so
├── libstdcxx.h
├── libstdcxx.modulemap
├── libswift_Concurrency.so
├── libswiftCore.so
├── libswiftCxx.a
├── libswiftCxxStdlib.a
├── libswiftDispatch.so
├── libswiftGlibc.so
├── libswiftRegexBuilder.so
├── libswift_RegexParser.so
├── libswiftRemoteMirror.so
├── libswift_StringProcessing.so
├── libswiftSwiftOnoneSupport.so
├── libXCTest.so
├── RegexBuilder.swiftmodule
│   ├── armv7-unknown-linux-gnueabihf.abi.json
│   ├── armv7-unknown-linux-gnueabihf.private.swiftinterface
│   ├── armv7-unknown-linux-gnueabihf.swiftdoc
│   ├── armv7-unknown-linux-gnueabihf.swiftinterface
│   └── armv7-unknown-linux-gnueabihf.swiftmodule
├── _RegexParser.swiftmodule
│   ├── armv7-unknown-linux-gnueabihf.abi.json
│   ├── armv7-unknown-linux-gnueabihf.private.swiftinterface
│   ├── armv7-unknown-linux-gnueabihf.swiftdoc
│   ├── armv7-unknown-linux-gnueabihf.swiftinterface
│   └── armv7-unknown-linux-gnueabihf.swiftmodule
├── _StringProcessing.swiftmodule
│   ├── armv7-unknown-linux-gnueabihf.abi.json
│   ├── armv7-unknown-linux-gnueabihf.private.swiftinterface
│   ├── armv7-unknown-linux-gnueabihf.swiftdoc
│   ├── armv7-unknown-linux-gnueabihf.swiftinterface
│   └── armv7-unknown-linux-gnueabihf.swiftmodule
├── SwiftOnoneSupport.swiftmodule
│   ├── armv7-unknown-linux-gnueabihf.abi.json
│   ├── armv7-unknown-linux-gnueabihf.private.swiftinterface
│   ├── armv7-unknown-linux-gnueabihf.swiftdoc
│   ├── armv7-unknown-linux-gnueabihf.swiftinterface
│   └── armv7-unknown-linux-gnueabihf.swiftmodule
├── Swift.swiftmodule
│   ├── armv7-unknown-linux-gnueabihf.abi.json
│   ├── armv7-unknown-linux-gnueabihf.private.swiftinterface
│   ├── armv7-unknown-linux-gnueabihf.swiftdoc
│   ├── armv7-unknown-linux-gnueabihf.swiftinterface
│   └── armv7-unknown-linux-gnueabihf.swiftmodule
└── x86_64
    ├── Dispatch.swiftdoc
    ├── Dispatch.swiftmodule
    ├── FoundationNetworking.swiftdoc
    ├── FoundationNetworking.swiftmodule
    ├── Foundation.swiftdoc
    ├── Foundation.swiftmodule
    ├── FoundationXML.swiftdoc
    ├── FoundationXML.swiftmodule
    ├── XCTest.swiftdoc
    └── XCTest.swiftmodule

I'm guessing that the armv7* files could probably be copied into swift.xctoolchain correct? And I'd imagine then that the *.so files for armv7 could then go into the SDK for the target. What do you think- how should this be setup?

[MaxDesiatov]

Can you include a preset that produces this output in your pull request and link that PR from here? Thanks!

[xtremekforever]

I added a new ticket to swiftlang/swift to track changes for adding official cross-compilation support to the build scripts:

swiftlang/swift#78960

My idea is to tackle it on a component-per-component basis to make sure nothing breaks in the process, since I see that the --cross-compile-hosts flag is used to build Apple platforms such as iOS, watchOS, etc.

I have several goals here, but the biggest goal is being able to build a linux-armv7 toolchain, with the eventual goal of supporting armv7 officially on swift.org and even generating Docker containers from the CI.

[xtremekforever]

@lhoward armhf support has been added to the swift-sdk-generator! All you need to do is this:

swift run swift-sdk-generator make-linux-sdk --swift-version 6.0.3-RELEASE \
    --target armv7-unknown-linux-gnueabihf \
    --target-swift-package-path ~/Downloads/swift-6.0.3-RELEASE-ubuntu-jammy-armv7-install

This assumes you have your own Swift 6.0.3 for armv7 built, or you download the one from my repo: https://github.com/xtremekforever/swift-armv7/releases/tag/6.0.3

I think this issue can be closed now that we have this support!