[SR-40] Port Swift to Linux on Raspberry Pi

[gribozavr]

Previous ID	SR-40
Radar	None
Original Reporter	@gribozavr
Type	New Feature
Status	Resolved
Resolution	Done

Attachment: Download

Additional Detail from JIRA

Votes	24
Component/s	Compiler, Foundation, Package Manager, Standard Library, XCTest
Labels	New Feature, NewPortRequest, arm
Assignee	@hpux735
Priority	Medium

md5: 7062026e0685ad58b94ffcbb4be1f47b

Sub-Tasks:

• SR-387 Undef. symbols when linking SwiftPM
• SR-359 Undef. symbols when linking to Foundation (ARM)

Issue Description:

It would be good to get Swift compiler running on Raspberry Pi, as well as having a cross-compiler from x86 to Raspberry Pi.

[hpux735]

I've started playing around with compiling on ARMv7, using a BeagleBone, rather than a RasPi. I encountered a clang++ crash during build:

{{
[174/1922] Building CXX object lib/IR/CMakeFiles/LLVMCore.dir/LegacyPassManager.cpp.o
FAILED: /usr/bin/clang++ -DGTEST_HAS_RTTI=0 -D_DEBUG -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -fPIC -fvisibility-inlines-hidden -Wall -W -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic -Wno-long-long -Wcovered-switch-default -Wnon-virtual-dtor -std=c++11 -fcolor-diagnostics -g -Ilib/IR -I/root/swift-build/llvm/lib/IR -Iinclude -I/root/swift-build/llvm/include -fno-exceptions -fno-rtti -MMD -MT lib/IR/CMakeFiles/LLVMCore.dir/Function.cpp.o -MF "lib/IR/CMakeFiles/LLVMCore.dir/Function.cpp.o.d" -o lib/IR/CMakeFiles/LLVMCore.dir/Function.cpp.o -c /root/swift-build/llvm/lib/IR/Function.cpp
clang: error: unable to execute command: Killed
clang: error: clang frontend command failed due to signal (use -v to see invocation)
Ubuntu clang version 3.6.0-2ubuntu1~trusty1 (tags/RELEASE_360/final) (based on LLVM 3.6.0)
Target: arm-unknown-linux-gnueabihf
Thread model: posix
clang: note: diagnostic msg: PLEASE submit a bug report to http://bugs.debian.org/ and include the crash backtrace, preprocessed source, and associated run script.
clang: note: diagnostic msg:
********************

PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang: note: diagnostic msg: /tmp/Function-8fe796.cpp
clang: note: diagnostic msg: /tmp/Function-8fe796.sh
clang: note: diagnostic msg:

********************
ninja: build stopped: subcommand failed.
utils/build-script: command terminated with a non-zero exit status 1, aborting
}}

The mentioned files are attached to this comment.

clang-crash-BeagleBoneBlack.tar.bz2

[gribozavr]

How much RAM does your device have? Building just LLVM and Clang requires more than 4 Gb, probably 8 Gb, IIRC. Building Swift requires 12 Gb if building with debug information (for the linking step).

I think you would want to try building a cross-compiler instead.

[hpux735]

Yep, you're right.

I found somewhere that using the release (-R) flag decreases memory requirements, and I added an moderate swapfile. I'm working on setting up a cross-compiling toolchain, but I've never had a good experience doing that, so I don't have high hopes. Currently it's about 1/2 finished compiling CLANG on the beaglebone. I expect that to finish perhaps tonight. 😉

I've also got a Jetson TK1 with 2GB of ram (the Beaglebone black has 512MB) that I can try.

[hpux735]

I think I'm on the right track with swift/utils/build-script-impl changes, and I tested that on Linux ARM and x86-64 (I haven't tested to make sure that changes don't hurt Darwin or FreeBSD yet). On x86-64, compilation completes successfully, and tests (1 unexpected failure, not sure if that means anything). On ARM, clang, cmark, and llvm build, swift doesn't; I'll start tackling that on monday.

https://github.com/hpux735/swift

[swift-ci]

Comment by Kody Holman (JIRA)

@hpux735 Would it be helpful to have an emulated raspberry pi running on a mac to get everything compiled?

[hpux735]

Yah, most likely. Can I give it a lot of ram? 🙂

[swift-ci]

Comment by Joe (JIRA)

@hpux735, I recommend looking into a Wandboard, particularly the Quad http://www.wandboard.org/. I have a a BeagleBoard X15 (http://www.elinux.org/Beagleboard:BeagleBoard-X15) that I'd be happy to test compiling and executing if you're using a specific branch.

It is the link steps that gobble the RAM, the X15 comes with 2GB and I had to add an 8G swapfile. Slow when it gets to those stages.

Let me know how I can help!

[swift-ci]

Comment by Kyle Frost (JIRA)

@hpux735 Looks like your GitHub says you have a working build. Does this mean you can actually run Swift on Raspberry Pi? Or build succeeds but it's broken.

[hpux735]

Thanks for those links, Joe. I've got a few Tegra TK1s with 2GB of ram, and they're doing alright. I'm looking into getting a Tegra TX1, which has 3GB. For building the debug variant, Nick (on the mailing list) reminded me that the 32 bit machines probably can't build it, no matter the swap size.

Kyle: I am able to build binaries for armv7l, but there is a problem in the linking stage somewhere. I'm getting an error "unexpected reloc type 0x03". So far, I haven't been able to figure out the root cause or a possible solution to that. I just don't have that great an understanding about how linking works at that level.

There was another pull request that solves an architecture dependency in the module.map for Glibc that I wanted to base my patch on, so I re-forked off the main apple repo, and I'm manually re-making the changes; it's still a little broken, but I expect that to be finished sometime today.

Ultimately, I think it's really, really close but I could use some help with that linking issue.

[swift-ci]

Comment by Félix Lapalme (JIRA)

I tried to build Swift on my Pi 2 about a week ago and ended up giving up because I always got a "memory exhausted" message when doing the final linking steps. I figured (after Googling a bit) it was because it was trying to work with files greater than 4GB and the Pi's 32 bit CPU couldn't handle that. You say the debug variant can't be built with a 32-bit processor, but can the "release" build be built with a 32 bit CPU?

I was using the -m option to use cmake instead of ninja. It worked quite well (with a few issues that I could easily work around) except for that 32-bit related memory issue. Did you try building it with that option ? Or is there some disadvantage to building it with cmake ?

[hpux735]

I have built using release mode on a BeagleBone Black, and on a Tegra TK1. Debug definitely doesn't work. I have tried on a Raspberry Pi, though with sufficient swap space, I don't see a reason why it wouldn't work.

I haven't tried using it with -m, so I don't know whether/how well it would work.

[swift-ci]

Comment by Mike Greiner (JIRA)

Has anyone tried cross-compiling the toolchain? That would certainly avoid the memory issues.

I've cross-compiled a few OSS projects before but I think this would be a bit beyond my expertise. If anyone's gotten a start on it though, I'd be happy to help out where I can.

[swift-ci]

Comment by Cody Krieger (JIRA)

mgreiner (JIRA User): I've started looking into reworking the build tooling to support cross-compilation in a generic way, but there are lots of assumptions that need to be changed in order to make that happen. No ETA yet.

[swift-ci]

Comment by Félix Lapalme (JIRA)

Someone already started to make cross compiling work for Android ( https://github.com/SwiftAndroid/swift ) maybe it would be a good starting point ?

With optimizations enabled and debugging disabled, my Pi seems to be compiling Swift quite well (98% done so far. I don't think it ever got this far). If I understood correctly, the 32-bit memory issues only occur when building Swift in debugging mode (so, without the -R argument for build-script)

[hpux735]

Thanks for reminding me about SwiftAndroid. That actually provided the key I needed to get swift linking correctly on ARMv7. I need to issue a pull request into the main repo, but for now, if you'd like to clone my repo, your compiler should be able to generate working executables.

https://github.com/hpux735/swift