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-1264] Swift doesn't build on Android #43872

Closed
swift-ci opened this issue Apr 19, 2016 · 29 comments
Closed

[SR-1264] Swift doesn't build on Android #43872

swift-ci opened this issue Apr 19, 2016 · 29 comments

Comments

@swift-ci
Copy link
Collaborator

swift-ci commented Apr 19, 2016

Previous ID SR-1264
Radar None
Original Reporter FlyingSnake (JIRA User)
Type Bug
Status Closed
Resolution Done

Attachment: Download

Environment

Ubuntu 14.04 (on Vagrant, VirtualBox, Mac OS X)

Additional Detail from JIRA
Votes 0
Component/s Compiler
Labels Bug, Android, Linux
Assignee @modocache
Priority Medium

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_eabi
Supported emulations: elf_x86_64 elf32_x86_64 elf_i386 i386linux elf_l1om elf_k1om i386pep i386pe

The buildbot_linux_arm7 command works fine without any issues.

I've attached the build log and I would really appreciate any help in getting this fixed.

@belkadan
Copy link
Contributor

belkadan commented Apr 19, 2016

cc @modocache

@modocache
Copy link
Mannequin

modocache mannequin commented Apr 19, 2016

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 CHANGELOG.md and source.properties files at the top level of your NDK directory. On older versions, you can check the RELEASE.txt file.

Until I can fix this issue, I'd recommend using android-ndk-r10e.

@modocache
Copy link
Mannequin

modocache mannequin commented Apr 19, 2016

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 --android-ndk-toolchain-version 4.9 to the build script. This defaults to 4.8, which appears to be gone in the latest NDK. Here's the new invocation you should use, in full:

$ ./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.9

2. The latest NDK now defines malloc_usable_size. I'll submit a pull request soon to get this working. For now, you can make the following source modification to your Swift checkout (easier to read version here):

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

@modocache
Copy link
Mannequin

modocache mannequin commented Apr 19, 2016

I'd appreciate some help from any Android developers out there that make frequent use of the NDK. Specifically:

  • 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.

@swift-ci
Copy link
Collaborator Author

swift-ci commented Apr 19, 2016

Comment by Sam Khawase (JIRA)

Hi Brian,

Thanks a lot for your help.
You've guessed correctly, I'm using android-ndk-r11c.

source.properties
Pkg.Desc = Android NDK
Pkg.Revision = 11.2.2725575

CHANGELOG.md
Hotfix r11c

I've applied your fix and started a clean build. I'll report back once it completes.

@swift-ci
Copy link
Collaborator Author

swift-ci commented Apr 19, 2016

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?
No. we use r11c

Is there ever a reason not to use the latest version of the Android NDK?
We use the NDK r11c because the latest NDK v12 broke our build and we had to revert back to r11c.

Which version would you expect Swift to support?
I would expect support for latest 2 NDK versions, only if it's easy to maintain.

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.
I think Swift should support a version that's not far from the latest, and just stick to it. As Android build works only in Linux, it's fairly easy to spin up a Vagrant/Docker/LXD box to build Swift toolchain. It would be great if we could provide a disclaimer in the Android.md manual for Swift. That way people won't try to compile against incompatible versions. (like I did).

@modocache
Copy link
Mannequin

modocache mannequin commented Apr 19, 2016

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.

@swift-ci
Copy link
Collaborator Author

swift-ci commented Apr 20, 2016

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?

libicu-build.log swift-build-r11c.log

@modocache
Copy link
Mannequin

modocache mannequin commented Apr 20, 2016

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.

@modocache
Copy link
Mannequin

modocache mannequin commented Apr 20, 2016

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

@swift-ci
Copy link
Collaborator Author

swift-ci commented Apr 20, 2016

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 buildbot_linux_armv7

Thanks a lot for all your help!

@modocache
Copy link
Mannequin

modocache mannequin commented Apr 20, 2016

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.

@swift-ci
Copy link
Collaborator Author

swift-ci commented Apr 20, 2016

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 😃

@modocache
Copy link
Mannequin

modocache mannequin commented Apr 20, 2016

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

@swift-ci
Copy link
Collaborator Author

swift-ci commented Apr 21, 2016

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.

/vagrant/android-sdk-linux/ndk-bundle/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/arm-linux-androideabi/bin/ld: error: cannot find -licuuc

/vagrant/android-sdk-linux/ndk-bundle/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/arm-linux-androideabi/bin/ld: error: cannot find -licui18n

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.

@swift-ci
Copy link
Collaborator Author

swift-ci commented Apr 22, 2016

Comment by Sam Khawase (JIRA)

@modocache I know you must be busy, but do you have any inputs on this error?

@modocache
Copy link
Mannequin

modocache mannequin commented Apr 22, 2016

I noticed you're passing --android-icu-uc /vagrant/libiconv-libicu-android/armeabi-v7a/libicuuc.so, passing the path to the .so directly. I always invoke it using --android-icu-uc /vagrant/libiconv-libicu-android/armeabi-v7a --android-icu-i18n /vagrant/libiconv-libicu-android/armeabi-v7a – in other words, passing the path to the directory. I just tried passing the paths directly like you do, and I got the exact same build error as you did!

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.

@modocache
Copy link
Mannequin

modocache mannequin commented Apr 22, 2016

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 -L /path/to/dir, not -L /path/to/dir/lib.so.

Apparently I mistakenly put the direct paths in the documentation--my bad!! Fixed in 2931c21

@swift-ci
Copy link
Collaborator Author

swift-ci commented Apr 22, 2016

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.

swift-build-1461357830.log

@modocache
Copy link
Mannequin

modocache mannequin commented Apr 22, 2016

Hmm, the missing symbols (uiter_setString_55, etc.) are indeed defined in libicuuc.so, so I can't imagine why it's unable to find them:

modocache@ubuntu:~$ readelf --symbols libiconv-libicu-android/armeabi-v7a/libicuuc.so | grep setString
  1932: 000ac744   196 FUNC    GLOBAL DEFAULT    8 uiter_setString_55

Here'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: 2

Could 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.

@swift-ci
Copy link
Collaborator Author

swift-ci commented Apr 22, 2016

Comment by Sam Khawase (JIRA)

@modocache
Here's the file info you requested.

vagrant@swift-buildbot:/vagrant$ readelf --symbols libiconv-libicu-android/armeabi-v7a/libicuuc.so | grep setString
  1917: 000ae578   200 FUNC    GLOBAL DEFAULT    8 uiter_setString_55

vagrant@swift-buildbot:/vagrant$ 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:          1405312 (bytes into file)
  Flags:                             0x5000200, Version5 EABI, soft-float ABI
  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: 23

@swift-ci
Copy link
Collaborator Author

swift-ci commented Apr 25, 2016

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 Hello.swift won't link using the command any more

vagrant@vagrant:/vagrant$ ./build/Ninja-ReleaseAssert/swift-linux-x86_64/bin/swiftc \
-target armv7-none-linux-androideabi \
-sdk /vagrant/android-sdk-linux/ndk-bundle/platforms/android-21/arch-arm \
-L /vagrant/android-sdk-linux/ndk-bundle/sources/cxx-stl/llvm-libc++/libs/armeabi-v7a \
-L /vagrant/android-sdk-linux/ndk-bundle/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/lib/gcc/arm-linux-androideabi/4.9/ \
-v \
hello.swift

Swift version 3.0-dev (LLVM 752e1430fc, Clang 1e6cba3ce3, Swift ca5d7bd204)
Target: armv7-none-linux-android
/vagrant/build/Ninja-ReleaseAssert/swift-linux-x86_64/bin/swift -frontend -c -primary-file hello.swift -target armv7-none-linux-android -disable-objc-interop -sdk /vagrant/android-sdk-linux/ndk-bundle/platforms/android-21/arch-arm -color-diagnostics -module-name hello -o /tmp/hello-5b7b22.o
/vagrant/build/Ninja-ReleaseAssert/swift-linux-x86_64/bin/swift-autolink-extract /tmp/hello-5b7b22.o -o /tmp/hello-e20020.autolink
/usr/bin/clang++ -fuse-ld=gold -target armv7-none-linux-androideabi /vagrant/build/Ninja-ReleaseAssert/swift-linux-x86_64/lib/swift/android/armv7/swift_begin.o /tmp/hello-5b7b22.o -L /vagrant/android-sdk-linux/ndk-bundle/sources/cxx-stl/llvm-libc++/libs/armeabi-v7a -L /vagrant/android-sdk-linux/ndk-bundle/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/lib/gcc/arm-linux-androideabi/4.9/ --sysroot /vagrant/android-sdk-linux/ndk-bundle/platforms/android-21/arch-arm -L /vagrant/build/Ninja-ReleaseAssert/swift-linux-x86_64/lib/swift/android -lswiftCore @/tmp/hello-e20020.autolink /vagrant/build/Ninja-ReleaseAssert/swift-linux-x86_64/lib/swift/android/armv7/swift_end.o -o hello
/usr/bin/ld.gold: fatal error: /vagrant/android-sdk-linux/ndk-bundle/platforms/android-21/arch-arm/usr/lib/../lib/crtbegin_dynamic.o: unsupported ELF machine number 40
clang: error: linker command failed with exit code 1 (use -v to see invocation)
<unknown>:0: error: link command failed with exit code 1 (use -v to see invocation)

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.

@modocache
Copy link
Mannequin

modocache mannequin commented Apr 25, 2016

Yes, it looks like the compiler is attempting to use /usr/bin/ld.gold. This won't work because that linker won't support Android. Instead, it needs to use the Android linker, included in android-ndk-r11c/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/arm-linux-androideabi/bin/ld.gold.

You should be able to fix this problem in several ways:

  1. Make sure android-ndk-r11c/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/arm-linux-androideabi/bin occurs earlier in your PATH than /usr/bin, at least when invoking swiftc.

  2. Symlink that linker to your /usr/bin:

$ 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.gold

Let me know which of the approaches you use and whether it works for you. I'll update the instructions!

@swift-ci
Copy link
Collaborator Author

swift-ci commented Apr 26, 2016

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.gold

Then I could compile the hello.swift program![]( Thank you so much) 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.
2. Still in step 1, in the instructions for building libiconv and libicu, users are told to run

git clone git@github.com:SwiftAndroid/libiconv-libicu-android.git

I'd change that to

git clone https://github.com/SwiftAndroid/libiconv-libicu-android.git

People may not have git credentials set up in their fresh new linux VM. But I'm nitpicking here 🙂
2. In step 2, Building the Swift stdlib for Android, the path to libicu/libiconv is ~/libicu-android, even though on step 1 the path is libiconv-libicu-android. Took me a few failures to realize that...
3. In step 3, Compiling hello.swift, the path to the built Swift compiler should be build/Ninja-ReleaseAssert/swift-linux-x86_64/bin/swiftc, instead of build/Ninja/ReleaseAssert/swift-linux-x86_64/swiftc.
4. As discussed above, also for step 3, there needs to be some workaround in place for using the correct ld.gold.
5. For step 4, actually running on a device:

$ adb shell LD_LIBRARY_PATH=/data/local/tmp hello

should be changed to:

$ adb shell LD_LIBRARY_PATH=/data/local/tmp /data/local/tmp/hello

That's it![]( Thanks so much again)

@swift-ci
Copy link
Collaborator Author

swift-ci commented Apr 26, 2016

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 :-)

@swift-ci
Copy link
Collaborator Author

swift-ci commented Apr 26, 2016

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 :-)

@swift-ci
Copy link
Collaborator Author

swift-ci commented Apr 26, 2016

Comment by Sam Khawase (JIRA)

Resolved all the pending issues, Swift compiles and runs on Android like charm.

@modocache
Copy link
Mannequin

modocache mannequin commented Apr 26, 2016

Excellent!! So glad to hear everyone got it building.

The linker issue is strange... I hesitate to recommend people move the ld.gold they have in their /usr/bin. I have both and things seem to be working for me:

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 -fuse-ld option, I wonder if that could be useful here...

Some follow ups:

@swift-ci
Copy link
Collaborator Author

swift-ci commented May 28, 2016

Comment by Haichuan Wang (JIRA)

Thanks Brian's great work! I also met the linker problem of Udi Wertheimer.
I had another workaround. I created the link

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.armv7

And pass a -use-ld=armv7 to swiftc, which will be used by clang as -fuse-ld, and it works.

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

No branches or pull requests

2 participants