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

[William Dillon]

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!!

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.  Because these triples don’t match, I have to force it with -target.  What is the desired direction here?  I’m happy to leave it armv7l and not have to dig into the triple determination logic, wherever it may live, but I can do that if we want to keep it armv7 everywhere (except for the references to armv7k for watchOS).  By the way, at first glance, it seems like foundation will build better using just ‘arm’ or ‘armv7’.

Thoughts/preferences?

Thanks!
- Will

> On Dec 15, 2015, at 2:52 AM, Dmitri Gribenko via swift-dev <swift-dev at swift.org> wrote:
> 
> On Tue, Dec 15, 2015 at 2:39 AM, Nick Wellnhofer via swift-dev
> <swift-dev at swift.org <mailto:swift-dev at swift.org>> wrote:
>> On 10/12/2015 00:05, William Dillon via swift-dev wrote:
>>> 
>>> At this point, the compiler and standard library are all built, and I
>>> think I have one final issue.  In the testing suite, the binaries generated
>>> by the swift compiler don’t run.  They’re emitting unexpected reloc type
>>> errors.  It appears that reolc type 0x03 is R_ARM_REL32 which is not
>>> permitted for use with shared libraries:
>>> 
>>> CollectionOfOne.swift.tmp/a.out: error while loading shared libraries:
>>> /home/wdillon/build/Ninja-ReleaseAssert/swift-linux-armv7/lib/swift/linux/libswiftCore.so:
>>> unexpected reloc type 0x03
>> 
>> 
>> Can you make sure you're compiling with the -fPIC flag? This is normally set
>> by CMake depending on the platform, but it's possible that CMake doesn't
>> know about Linux-ARM yet.
> 
> Good point.  Another possibility is that it could be that the Swift compiler
> is not setting the PIC flag when setting up LLVM for Linux/arm.
> 
> This is one of the reasons why isolating the issue to specific symbols
> would be very interesting, it would allow us to focus on a specific
> object file.
> 
> 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 <mailto:gribozavr at gmail.com>>*/
> _______________________________________________
> swift-dev mailing list
> swift-dev at swift.org <mailto:swift-dev at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-dev <https://lists.swift.org/mailman/listinfo/swift-dev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20151216/55b1304a/attachment.html>