[swift-dev] [SR-40] Port Swift to Arm progress / question

[Dmitri Gribenko]

On Wed, Dec 16, 2015 at 11:55 AM, William Dillon
<wdillon at coas.oregonstate.edu> wrote:
> Hi all,
>
> I think that I’ve found the culprit with linking errors on ARMv7-linux.  I was looking at the changes between the SwiftAndroid port, and I noticed an extra flag they added in the AddSwift cmake module: -Wl,-Bsymbolic.  I added that to my copy of the module, and re-built swift.  I’m now able to compile and run a hello world program:
>
> $ cat hello.swift
> print("Hello world!")
> $ swiftc hello.swift
> $ ./hello
> Hello world!
> $ uname -s -m
> Linux armv7l
>
> -target is not required, and no linker/loader errors!!

Awesome!

> I just finished building and testing on linux-x86_64 and mac, and I don’t think I’ve added any regressions.  I’m starting to clean up to submit a new pull request to the apple repo.  To that end, I had been required to add -target armv7-unknown-linux-gnueabihf to the swiftc invocation while using armv7 as the architecture.  Apparently, swiftc is getting a triple from the OS somehow, and that triple has armv7l-unknown-linux-gnueabihf.

I think we should make sure that autodetection works correctly (that
is, so that using the armv7l autodetected triple does not confuse the
compiler).  I think we should make adjustments in the directory names
and everywhere else to ensure that we use 'armv7l' consistently.  I'm
asking Tim Northover to confirm that this is the right thing.

Dmitri

-- 
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr at gmail.com>*/