Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

armhf support #65

Open
lhoward opened this issue Jan 10, 2024 · 9 comments
Open

armhf support #65

lhoward opened this issue Jan 10, 2024 · 9 comments

Comments

@lhoward
Copy link

lhoward commented Jan 10, 2024

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

@MaxDesiatov
Copy link
Contributor

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
Copy link
Author

lhoward commented Jan 10, 2024

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
Copy link

xtremekforever commented Jul 7, 2024

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
Copy link
Contributor

MaxDesiatov commented Jul 7, 2024

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
Copy link

xtremekforever commented Jul 7, 2024

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
Copy link
Contributor

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
Copy link

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
Copy link

@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
Copy link
Contributor

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants
@MaxDesiatov @lhoward @xtremekforever and others