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

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

swift-ci opened this issue Jan 26, 2016 · 3 comments


Copy link

@swift-ci swift-ci commented Jan 26, 2016

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

Raspberry Pi 2 running Raspbian Jessie
Build Swift using MoriMori's guide of building Swift:
(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.)

Copy link

@belkadan belkadan commented Jan 26, 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.)

Copy link
Collaborator Author

@swift-ci swift-ci commented Jan 26, 2016

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
-emit-module -module-name MyTarget -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.)

Copy link

@belkadan belkadan commented Jan 26, 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.)

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet

No branches or pull requests

2 participants