[SR-623] swift (front-end tool) looks for wrong 'armv*' target on Raspberry Pi

[swift-ci]

Previous ID	SR-623
Radar	None
Original Reporter	ewmailing (JIRA User)
Type	Bug

Environment

Raspberry Pi 2 running Raspbian Jessie
Build Swift using MoriMori's guide of building Swift:
http://morimori.tokyo/2016/01/05/how-to-compile-swift-on-a-raspberry-pi-2/
(I'm currently using Option 3)

Additional Detail from JIRA

Votes	0
Component/s	Compiler
Labels	Bug, Linux, arm, armhf
Assignee	None
Priority	Medium

md5: 7d4d363053081c63f3794de382766057

Issue Description:

I was told to file a bug by William Dillon (hpux735) who has been doing arm work for Swift.

When I try to invoke the 'swift' front end compiler (not 'swiftc') on the Raspberry Pi 2, I get an error message like:
error: unable to load standard library for target ‘armv7l-unknown-linux-gnueabi’

which prevents it from working.

William Dillion says he's been doing work to canonicalize all instances of armv?l into armv?. However, he hasn't focused on the 'swift' compiler (mostly 'swiftc').

As a temporary workaround, I can specify
-target armv7-unknown-linux-gnueabihf

However, the reason I am using 'swift' instead of 'swiftc' is because I'm working on a general Swift backend for CMake so it can handle projects with Swift files. The 'swift' front-end design has the least impedance with the CMake design in that CMake does incremental, file-by-file compilations instead of one-shot-all-files which 'swiftc' wants. (But I can't really put the -target hack into the CMake core because this same code is run on all the other Linux platforms/arch's.)

[belkadan]

'swift' is the interpreter. 'swift -frontend' is an internal, unstable interface that is not suitable for calling from anywhere else. And CMake's "file-at-a-time" approach is not compatible with Swift's implicit cross-file visibility—that's why it has its own dependency analysis system.

(Hi, Eric. Doug showed me that you and others were starting to work on CMake support for Swift, and I've been meaning to chime in on your thread to help you out. Feel free to pull me into a discussion there.)

[swift-ci]

Comment by Eric Wing (JIRA)

Drat. I've been cross-verifying with what Xcode does.
The file at a time thing seemed to work as long as I passed the list of all Swift files, which was doable with minor changes to CMake internals.

This is what the invocation looks like roughly right now:
swift -frontend -c -primary-file
/Volumes/DataPartition/Users/ewing/Source/CodeTest/CMakeSwiftBasic/OtherSwift.swift
/Volumes/DataPartition/Users/ewing/Source/CodeTest/CMakeSwiftBasic/main.swift
-emit-module -module-name MyTarget -o
CMakeFiles/MyApp.dir/OtherSwift.o

Changes to use swiftc look like it will require more drastic changes to CMake internals. (I'm not an official (skilled) CMake maintainer and am doing this on my own time, so this could effectively turn into something that kills this endeavor.)

[belkadan]

Yeah, that's debug output more than a supported interface. You could get the commands swiftc would actually run, but that still won't do a real job tracking what does and doesn't need to be recompiled. (And that skips the merging of the individual module files into a single module at the end, which you need to do for a library or proper debugging.)