[SR-1264] Swift doesn't build on Android #43872
Comments
|
cc @modocache |
|
When using the latest Android NDK release, android-ndk-r11c, I encounter the exact same error message during compilation. Full log: https://gist.github.com/modocache/4bfce5c26319b7e0cc11e643a126bab5 I figure that either the problem is due to the NDK release version (I've only tested this on android-ndk-r10e, the latest release at the time I began working on Android), or that I had some sort of local modification to my copy of android-ndk-r10e that made it work. I'm currently investigating. FlyingSnake (JIRA User), could you please tell me what version of the NDK you're using? You may be able to tell by looking at the Until I can fix this issue, I'd recommend using android-ndk-r10e. |
|
FlyingSnake (JIRA User): In the immediate short-term, you should be able to get the Android build working with android-ndk-r11c (the latest NDK version) with two small modifications: 1. Supply $ ./swift/utils/build-script \
-R \
--android \
--android-ndk /vagrant/android-sdk-linux/ndk-bundle \
--android-ndk-version 21 \
--android-icu-uc /vagrant/libiconv-libicu-android/armeabi-v7a/libicuuc.so \
--android-icu-uc-include /vagrant/libiconv-libicu-android/armeabi-v7a/icu/source/common \
--android-icu-i18n /vagrant/libiconv-libicu-android/armeabi-v7a/libicui18n.so \
--android-icu-i18n-include /vagrant/libiconv-libicu-android/armeabi-v7a/icu/source/i18n/ \
--android-ndk-toolchain-version 4.92. The latest NDK now defines diff --git a/stdlib/public/stubs/LibcShims.cpp b/stdlib/public/stubs/LibcShims.cpp
index cb750f1..a3164fa 100644
--- a/stdlib/public/stubs/LibcShims.cpp
+++ b/stdlib/public/stubs/LibcShims.cpp
@@ -52,7 +52,7 @@ int _swift_stdlib_close(int fd) { return close(fd); }
#if defined(__APPLE__)
#include <malloc/malloc.h>
size_t _swift_stdlib_malloc_size(const void *ptr) { return malloc_size(ptr); }
-#elif defined(__GNU_LIBRARY__) || defined(__CYGWIN__)
+#elif defined(__GNU_LIBRARY__) || defined(__CYGWIN__) || defined(__ANDROID__)
#include <malloc.h>
size_t _swift_stdlib_malloc_size(const void *ptr) {
return malloc_usable_size(const_cast<void *>(ptr));
@@ -62,13 +62,6 @@ size_t _swift_stdlib_malloc_size(const void *ptr) {
size_t _swift_stdlib_malloc_size(const void *ptr) {
return malloc_usable_size(const_cast<void *>(ptr));
}
-#elif defined(__ANDROID__)
-extern "C" {
-extern size_t dlmalloc_usable_size(void*);
-}
-size_t _swift_stdlib_malloc_size(const void *ptr) {
- return dlmalloc_usable_size(const_cast<void *>(ptr));
-}
#else
#error No malloc_size analog known for this platform/libc.
#endif |
|
I'd appreciate some help from any Android developers out there that make frequent use of the NDK. Specifically:
|
|
Comment by Sam Khawase (JIRA) Hi Brian, Thanks a lot for your help.
I've applied your fix and started a clean build. I'll report back once it completes. |
|
Comment by Sam Khawase (JIRA) Hi Brian, I use NDK regularly. The project is a fairly complex cross-platform app(s) with UI layers in native (Android/iOS) and almost 80-85% code base is C++ (I dream of replacing C++ with Swift one day) Do you use the latest version of the NDK? Is there ever a reason not to use the latest version of the Android NDK? Which version would you expect Swift to support? Should Swift attempt to support multiple versions? This seems like it would take quite a bit of effort, so I'd like to avoid this if possible. |
|
Excellent, thanks FlyingSnake (JIRA User). Here's a pull request that should resolve this issue: #2244 I think this and #2242 would unbreak the Swift Android build on master. My apologies: ideally the build wouldn't have been broken for a day in the first place. I'm working on supporting the test suite on Android in #1714 and after that's done I'm hoping to set up some sort of local CI so that I can report failures faster in the future. |
|
Comment by Sam Khawase (JIRA) Hi @modocache I've tried the build and unfortunately it's still broken. I think the culprit is the libiconv-libicu-android which doesn't get compiled under NDK r11c. I've attached the error logs and will try to compile using NDK r10e and see if I can build Swift. Are there prebuilt binaries for Swift for Android, which can be made available to everyone? Also can we spin up an instance of Travis CI for Android builds, since they are free for open-source projects? |
|
Thanks for the additional attachments! Yes, the libicu build script needs to be updated (see https://twitter.com/neonacho/status/722750280161476609). I believe it'll work if you remove the check described in that tweet--will push a fix to that repo shortly. |
|
FlyingSnake (JIRA User), I just merged SwiftAndroid/libiconv-libicu-android#2 into SwiftAndroid/libiconv-libicu-android. That build now works with android-ndk-r11c. Travis CI is a good idea. We unfortunately can't use it on the main apple/swift repository, though (I do want to think whether we can get Swift on Android incorporated into the main CI some day). We could use Travis if we set up a mirror repository that periodically rebased on top of master. Setting that up would take a bit of effort... any help there would be much appreciated. And yes, packaging binaries is a great idea. I created a GitHub release, you can download the build products from there: https://github.com/SwiftAndroid/libiconv-libicu-android/releases/tag/android-ndk-r11c |
|
Comment by Sam Khawase (JIRA) Man I am seriously impressed by your dedication to this project. Not only you are a kick-ass programmer, but you've got crazy enthusiasm in addition! I'll get back to compiling Swift4Android and hopefully will succeed this time :-D. I'll probably create a vagrant box with Ansible provisioning to help people spin up a Swift-build-bot OR investigate how to create the builtbot preset like Thanks a lot for all your help! |
|
Haha, thanks!! 🙂 Also, thank you for kicking the tires on this the Swift Android build. Only a handful of people have attempted to build it since it was merged. Feedback at this early stage is an important part of making it stable for everyone. |
|
Comment by Sam Khawase (JIRA) I'll try to get the Travis CI build up once my vagrant swift build-bot is ready. Once we've a CI for Swift/Android, people will know we mean serious business 😃 |
|
FYI: If you pull from apple/swift master, you'll encounter an entirely different build error. Apply #2252 in order to fix it. Our CI strategy can't come soon enough! 🙂 |
|
Comment by Sam Khawase (JIRA) Sigh, one more build failure on NDK r11c. I did a clean build of libicu and latest Swift from upstream, and it still failed at linker stage. I tried re-running the build script and got more details about the error.
Looks like the linker isn't happy with the libicu that we're passing as a parameter. swift-build-1461231397.log and swift-build-1461233286.log I noticed that you're using Ubuntu 15.10 and I'll try to spin up another vagrant box to verify if it builds on 15.10 (I'm on Trusty LTS). Once I get a solid build, I'll start a Travis CI job and hopefully we'll have better integration. |
|
Comment by Sam Khawase (JIRA) @modocache I know you must be busy, but do you have any inputs on this error? |
|
I noticed you're passing Looks like I need to fix the documentation/linker steps in the Android build script. Perhaps we rely on more than just libicuuc and libicui18n – looks like we also rely on another library in there...? In the short term, try passing the directory paths instead for now. |
|
It seems like the missing symbols from your log (and from when I reproduced it locally) are actually in libicuuc.so, so I think the problem here is actually just that we need to Apparently I mistakenly put the direct paths in the documentation--my bad!! Fixed in 2931c21 |
|
Comment by Sam Khawase (JIRA) @modocache Sorry but Swift still gives no dice :'( I cleaned, updated from git upstream and rebuilt Swift again with r11c, and it still won't build. It fails at the linker stage again. Is it the vagrant box or Ubuntu 14.04 the problem? I'm not sure if I'm doing something wrong. Thanks for your patience, it's really an uphill task getting swift to build. |
|
Hmm, the missing symbols ( modocache@ubuntu:~$ readelf --symbols libiconv-libicu-android/armeabi-v7a/libicuuc.so | grep setString
1932: 000ac744 196 FUNC GLOBAL DEFAULT 8 uiter_setString_55Here's the headers from that .so: modocache@ubuntu:~$ readelf -h libiconv-libicu-android/armeabi-v7a/libicuuc.so
ELF Header:
Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: DYN (Shared object file)
Machine: ARM
Version: 0x1
Entry point address: 0x0
Start of program headers: 52 (bytes into file)
Start of section headers: 1393000 (bytes into file)
Flags: 0x5000000, Version5 EABI
Size of this header: 52 (bytes)
Size of program headers: 32 (bytes)
Number of program headers: 8
Size of section headers: 40 (bytes)
Number of section headers: 24
Section header string table index: 2Could you try running the above commands to confirm that you see the same output? Specifically, the library should be built for ARM, and it should contain the symbol text "setString". I'm currently running a clean, verbose build, in order to see what differs between your output and mine. |
|
Comment by Sam Khawase (JIRA) @modocache |
|
Comment by Sam Khawase (JIRA) @modocache Finally made it work! I think the error was with the vagrant + Ubuntu Trusty Virtualbox image. So I ditched it, spun a new Ubuntu 15.10 and rebuilt everything from scratch, and it finally worked as a charm. However the program My coworker also go the same error, when he tried it on his machine. Do you think there's something missing here in this command? P.S. I'm still working on the Travis CI job, and will update you once I got it setup. |
|
Yes, it looks like the compiler is attempting to use You should be able to fix this problem in several ways:
$ sudo ln -s \
android-ndk-r11c/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/arm-linux-androideabi/bin/ld.gold \
/usr/bin/armv7-none-linux-androideabi-ld.goldLet me know which of the approaches you use and whether it works for you. I'll update the instructions! |
|
Comment by Udi Wertheimer (JIRA) Oh wow, I'm so happy I found this thread! :'D I too just couldn't build swift on 14.04. When I tried 15.10, Swift built but I couldn't use it to compile for android, with the linking failing because of usr/bin/ld.gold. @modocache, I tried both your suggestions, updating the PATH and symlinking to /usr/bin. Both didn't help. I had to move my current /usr/bin/ld.gold, and symlink the android linker to that exact location (at least temporarily): $ sudo mv /usr/bin/ld.gold /usr/bin/ld.gold.old
$ sudo ln -s \
android-ndk-r11c/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/arm-linux-androideabi/bin/ld.gold \
/usr/bin/ld.goldThen I could compile the hello.swift program This is very exciting 🙂 I have a few more small fixes for the android documentation: 1. The prebuilt libiconv-libicu-android binaries linked to in step 1 are currently broken, it's an empty zip file (there's just one empty folder inside). Compiling from source using the instructions does work. git clone git@github.com:SwiftAndroid/libiconv-libicu-android.gitI'd change that to git clone https://github.com/SwiftAndroid/libiconv-libicu-android.gitPeople may not have git credentials set up in their fresh new linux VM. But I'm nitpicking here 🙂 $ adb shell LD_LIBRARY_PATH=/data/local/tmp helloshould be changed to: $ adb shell LD_LIBRARY_PATH=/data/local/tmp /data/local/tmp/helloThat's it |
|
Comment by Sam Khawase (JIRA) Hi udiWertheimer (JIRA User) Thanks a lot for testing this out! I'm glad you made it work. I was stuck at the ld phase and looks like you've provided a clean solution. I'll test it out from scratch again and see if it works as advertised :-) |
|
Comment by Sam Khawase (JIRA) Greetings @modocache and udiWertheimer (JIRA User) ! I can confirm that the whole setup now works and I can cross-compile the Hello.swift and run it on Android device, thanks to the wonderful update by udiWertheimer (JIRA User). I think we should update the Android.md document on Swift repo and close this ticket. Swift working on Android is the harbinger of great things, and I can't wait for swift to be first-class citizen on all platforms. Thanks a lot for your help guys :-) |
|
Comment by Sam Khawase (JIRA) Resolved all the pending issues, Swift compiles and runs on Android like charm. |
|
Excellent!! So glad to hear everyone got it building. The linker issue is strange... I hesitate to recommend people move the modocache@ubuntu:~$ la /usr/bin/*ld.gold
/usr/bin/armv7-none-linux-androideabi-ld.gold /usr/bin/ld.gold /usr/bin/x86_64-linux-gnu-ld.gold
modocache@ubuntu:~$ /usr/bin/ld.gold --version
GNU gold (GNU Binutils for Ubuntu 2.25.1) 1.11
Copyright (C) 2014 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) a later version.
This program has absolutely no warranty.
modocache@ubuntu:~$ /usr/bin/armv7-none-linux-androideabi-ld.gold --version
GNU gold (binutils-2.25-48ba864 2.25.51.20141117) 1.11
Copyright (C) 2015 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) a later version.
This program has absolutely no warranty.I'll look into this more. Also, I don't like the idea of requiring users to symlink anything at all. I wonder if it would be possible to pass a linker path to the Swift compiler when invoking it. I know of the Some follow ups:
|
|
Comment by Haichuan Wang (JIRA) Thanks Brian's great work! I also met the linker problem of Udi Wertheimer. sudo ln -s \
/path/to/android-ndk-r11c/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/arm-linux-androideabi/bin/ld.gold \
/usr/bin/ld.armv7And pass a -use-ld=armv7 to swiftc, which will be used by clang as -fuse-ld, and it works. |
Attachment: Download
Environment
Ubuntu 14.04 (on Vagrant, VirtualBox, Mac OS X)
Additional Detail from JIRA
md5: c10475de3cf77c747adcf7824abe13c5
Issue Description:
strong textHi,
I've setup a vagrant box with Ubuntu 14.04 and followed the instructions at https://github.com/apple/swift/blob/master/docs/Android.md. The compilation fails at the linker stage showing the error
/usr/bin/ld: unrecognised emulation mode: armelf_linux_eabiSupported emulations: elf_x86_64 elf32_x86_64 elf_i386 i386linux elf_l1om elf_k1om i386pep i386peThe
buildbot_linux_arm7command works fine without any issues.I've attached the build log and I would really appreciate any help in getting this fixed.
The text was updated successfully, but these errors were encountered: