Proof-of-concept port of Swift for Android

Hello,
I'm currently working on adding support to the Swift compiler to allow it to target Android. Currently I've managed to get the stdlib to compile after hacking around/disabling a bunch of stuff (the custom linker script, the dl_iterate_phdr stuff, and the posix_spawn support), and managed to compile and run the simplest proof-of-concept (import Glibc; exit(42)).
My fork is located at GitHub - SwiftAndroid/swift: Port of Apple's reference Swift toolchain to Android; doesn't quite work yet and I would really appreciate any comments and suggestions.
In particular, I would like some help on the following issues:
- The current build system assumes that the host and the target has the same version of libicu. Android doesn't ship with libicu, so I had to point the build script to a copy of libicu manually. However, the same ICU include path is used to compile all target stdlibs,including the host one, so I had to make sure that my libicu headers matches the host one. Is there a way for me to specify in the build system to use a different libicu for one of the targets?
- The current stdlib build system also assumes that the host and the target are of the same OS family, so currently only Linux hosts can target Android. Is there anything I can do to allow Mac hosts to also target Android?
- What's the role of the special linker script, and what's the purpose of the conformance tables in shared libraries? I've commented the conformance table loading code out on Android; is that why 'print("Hello world")' prints out "String(" infinity?
- How should Swift integrate with the Android NDK?
- The version of Clang shipped with Ubuntu 15.10 can't seem to find the arm-linux-androideabi-ld linker even though I've pointed it to the Android NDK's copy via -gcc-toolchain. It only seems to check /usr/bin/armv7-none-linux-androideabi-ld before falling back to /usr/bin/ld. The Clang from the Android NDK can find the NDK ld fine. Is there a particular command line option I need to pass into the Ubuntu clang to make it look for the arm-linux-androideabi-ld in the gcc-toolchain folder?
Thank you for your help and for your work on Swift.
Zhuowei Zhang

I'm currently working on adding support to the Swift compiler to allow it to target Android.

Cool. Responding to one specific issue:

- What's the role of the special linker script, and what's the purpose of the conformance tables in shared libraries? I've commented the conformance table loading code out on Android; is that why 'print("Hello world")' prints out "String(" infinity?

The linker script allows the compiler to be able to enumerate conformance tables, which are part of reflection information. I’m not an expert in this area (Joe Groff or John McCall could better respond) but I would completely believe the are the reason for your print failure. print is defined as taking an Any, and does a downcast to a protocol, and that is probably failing.

-Chris

···

On Dec 8, 2015, at 8:50 PM, Zhuowei Z via swift-dev <swift-dev@swift.org> wrote:

Yes, this is exactly the problem. You'll need some way for the conformance sections from every .o file to be collected into a section of the final binary that the runtime can consult at runtime in swift_conformsToProtocol. Can the existing swift.ld script be adapted to work on Android?

-Joe

···

On Dec 8, 2015, at 8:57 PM, Chris Lattner via swift-dev <swift-dev@swift.org> wrote:

On Dec 8, 2015, at 8:50 PM, Zhuowei Z via swift-dev <swift-dev@swift.org <mailto:swift-dev@swift.org>> wrote:

I'm currently working on adding support to the Swift compiler to allow it to target Android.

Cool. Responding to one specific issue:

- What's the role of the special linker script, and what's the purpose of the conformance tables in shared libraries? I've commented the conformance table loading code out on Android; is that why 'print("Hello world")' prints out "String(" infinity?

The linker script allows the compiler to be able to enumerate conformance tables, which are part of reflection information. I’m not an expert in this area (Joe Groff or John McCall could better respond) but I would completely believe the are the reason for your print failure. print is defined as taking an Any, and does a downcast to a protocol, and that is probably failing.