[SR-623] swift (front-end tool) looks for wrong 'armv*' target on Raspberry Pi Created: 26 Jan 2016  Updated: 12 Sep 2017

Status: Open
Project: Swift
Component/s: Compiler

Type: Bug Priority: Medium
Reporter: Eric Wing Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: Linux, arm, armhf
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)



 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.)



 Comments   
Comment by Jordan Rose [ 26 Jan 2016 ]

'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.)

Comment by Eric Wing [ 26 Jan 2016 ]

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.)

Comment by Jordan Rose [ 26 Jan 2016 ]

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.)

Generated at Mon Dec 10 22:13:36 CST 2018 using Jira 7.13.0#713000-sha1:fbf406879436de2f3fb1cfa09c7fa556fb79615a.