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

App fails do find symbols in icui18n.so #2

Open
jotdl opened this issue May 25, 2016 · 4 comments
Open

App fails do find symbols in icui18n.so #2

jotdl opened this issue May 25, 2016 · 4 comments

Comments

@jotdl
Copy link

jotdl commented May 25, 2016

Hey,

I completed all tasks on how to build the samples app.
I did:

  • Compilation of libiconv-libicu for android
  • Compilation of swift for android
  • Compilation of swift-pm
  • Compilation of gradle-plugin
  • Compilation of swift-android-samples.

Due the gradle-plugin does not package the libicu*.so at the moment, I added them to the jniLibs directory to get a standalone apk. For everything else I followed the guide available at https://github.com/apple/swift/blob/master/docs/Android.md.

But when I run the application on an actual device I receive the following exception:

java.lang.UnsatisfiedLinkError: dlopen failed: cannot locate 
symbol "ucol_strcoll_55" referenced by "libswiftCore.so"...
       at java.lang.Runtime.loadLibrary(Runtime.java:371)
       at java.lang.System.loadLibrary(System.java:988)
       at net.zhuoweizhang.swifthello.SwiftHello.loadNativeDependencies(SwiftHello.java:30)
       at net.zhuoweizhang.swifthello.SwiftHello.onCreate(SwiftHello.java:15)
       at android.app.Activity.performCreate(Activity.java:6185)
       at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1118)
       at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2650)
       at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2771)
       at android.app.ActivityThread.access$900(ActivityThread.java:177)
       at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1432)
       at android.os.Handler.dispatchMessage(Handler.java:102)
       at android.os.Looper.loop(Looper.java:135)
       at android.app.ActivityThread.main(ActivityThread.java:5912)
       at java.lang.reflect.Method.invoke(Native Method)
       at java.lang.reflect.Method.invoke(Method.java:372)
       at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:1405)
       at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1200)

This is thrown when libswiftCore is about to be loaded. I checked all libraries and the 'ucol_strcoll_55' symbol is available in libicui18n.so which is loaded before.

System enviroment:

  • Ubuntu 15.04
  • Android NDK r11c
  • Android SDK 24.4.1
  • Android Build-Tools: 23.0.3

Do you know what goes wrong?

Thanks for your help!

@jotdl
Copy link
Author

jotdl commented May 26, 2016

I got a bit further. Already found that 'ucol_strcoll_55' seems to be statical linked into libswiftCore nowadays. I don't understand why this symbol can't be resolved then still.

@s1ddok
Copy link

s1ddok commented Dec 19, 2016

Faced the same problem, did you ever found a solution?

@jotdl
Copy link
Author

jotdl commented Dec 20, 2016

No sadly not. I was investigating different programming languages to use natively on mobile platforms. Because I did not want to spend more time resolving this issue on android, we went with another language.

As far as I remember, android devices often come with preinstalled/preloaded versions of libicui18n.so. If that's the case they're not loaded again when an android application tries to load it's custom version. If any symbols are missing in the preloaded version the mentioned exception occurs. If I remember right, the only solution (which was proposed) would be to have one statically linked (fat) library which contains all required symbols.

But because the swift tooling was not there at that time to produce fat libraries, I just stoped spending time on it. Don't know if this has changed since then.

@jotdl jotdl closed this as completed Dec 20, 2016
@jotdl jotdl reopened this Dec 20, 2016
@s1ddok
Copy link

s1ddok commented Dec 20, 2016

It’s being solved by statically linking libicui18n when creating the final executable file.
This is done by passing -Xlinker -licui18n -Xlinker -L<path_to_libicu>

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants