Android NDK: Issue with external dependencies

[XperielIndigo]

Hi everyone,

I've got an android app that primarily uses the NDK. Almost everything is working. The current issue happens when loading the library (System.loadLibrary) it throws the error: java.lang.UnsatisifedLinkError: dlopen failed: could not load library "libfreetype.so" needed by "libwrapper.so"; caused by library "libfreetype.so" not found.

My android_binary is called wrapper and I've got a dependency in a cc_library to //external:freetype which imports libfreetype.so.

Any thoughts?

Cheers
Indigo

[XperielIndigo]

My freetype artifact is:

# In artifact BUILD
cc_library(
  name = "freetype-cc",
  srcs = ["android/libfreetype.so"],
  hdrs = glob(["include/**/*.h"]),
  includes = ["include"],
  visibility = ["//visibility:public"],
)

# In my WORKSPACE
http_archive(
  name = "freetype-archive",
  url = "URL/HERE",
  sha256 = "SHA",
)
bind(
  name = "freetype-cc",
  actual = "@freetype-archive//:freetype-cc",
)

Thanks

[kchodorow]

Could you run bazel build --verbose_failures //your:target and paste the output? That should give us the full command line it's trying to run.

[XperielIndigo]

It doesn't fail at compile, it fails on System.loadLibrary(). Is there some other output I can provide?

[mrdomino]

Sounds like a duplicate of issue #335. Workaround here:

#335 (comment)

[XperielIndigo]

I updated to that hash and even tried giving the --fat_apk_cpu=armeabi-v7a flag. It still fails.

[mrdomino]

D'oh, ok, never mind.

[damienmg]

Closing, please follow-up on #335

[XperielIndigo]

I don't think this is a duplicate, #335 has the issue of not finding a symbol, I have the issue of not finding the library.

[damienmg]

Right sorry, Adding alex for insight on android

[damienmg]

+Alex Humesky

Alex, can you have a look at this bug?

On Fri, Aug 7, 2015 at 4:14 PM Indigo Orton notifications@github.com
wrote:

I don't think this is a duplicate, #335
#335 has the issue of not finding
a symbol, I have the issue of not finding the library.

—
Reply to this email directly or view it on GitHub
#357 (comment).

[ahumesky]

Could you do unzip -l on the bulit apk to see if it ends up there?

[XperielIndigo]

Output of unzip -l bazel-myproject/bazel-out/local_darwin-fastbuild/bin/src/main/java/com/mycompany/android/api/wrapper_incremental.apk

     2188  08-07-15 17:49   AndroidManifest.xml
    16028  08-07-15 17:46   classes.dex
       13  08-07-15 17:46   nativedeps
       47  08-07-15 17:46   stub_application_data.txt
 15420488  08-07-15 17:49   lib/armeabi-v7a/libwrapper.so
      411  08-07-15 17:49   META-INF/MANIFEST.MF
      464  08-07-15 17:49   META-INF/CERT.SF
     1203  08-07-15 17:49   META-INF/CERT.RSA

That is the only apk that was discovered from a find bazel-myproject/ -name "*.apk"

[ahumesky]

Looks like you're using bazel mobile-install, which is fine, but could you try "bazel build" of the same target? That should give you a regular apk, at bazel-bin/src/main/java/com/yourcompany/android/api/wrapper.apk That might not fix it, but it at least would eliminate mobile-install as a culprit.

And to make sure I understand your setup, I see that the apk has "libwrapper.so". Is that from a rule in a different package as the android_binary? libwrapper.so would be the output of a cc_library named "wrapper", and your android binary is already named "wrapper", so they couldn't be from the same package. Also you mentioned "//external:freetype", but did you mean "//external:freetype-cc"?

So you have an android_binary named "wrapper" that depends on a cc_library named "wrapper" in a different package that depends on "//external:freetype-cc", which is bound to "@freetype-archive//:freetype-cc", which is the cc_library rule named "freetype-cc" in the BUILD file in the zip file from the http_archive rule, right?

[XperielIndigo]

I can't seem to do a bazel build because I need the configuration of a mobile-install for some select dependency statements.

As for my setup I have:

android_binary(
  name = "wrapper",
  srcs = ["MainActivity.java"],
  manifest = "AndroidManifest.xml",
  legacy_native_support = 0,
  deps = [
    ":api",
    ":jni",
  ],
)

android_library(
  name = "api",
  srcs = glob(["*.java"], exclude = ["MainActivity.java"]),
)

cc_library(
  name = "jni",
  srcs = glob(["*.cc"]),
  hdrs = glob(["*.h"]),
  deps = [
    "//src/main/cc/com/mycompany/api",
  ],
  linkopts = ["-lGLESv2", "-lEGL", "-llog"],
)

and the external http_archive above. I've tried naming my external archive library freetype and freetype-cc to test whether it was something to do with that name (it doesn't appear so).

The only rule named wrapper is the android_binary

[ahumesky]

I see you have legacy_native_support = 0, which means that all of the native libraries will be linked together into one .so:
https://github.com/google/bazel/blob/49543429f56cfe9c90562a1e9f9c66a9eabb5385/src/main/java/com/google/devtools/build/lib/rules/android/AndroidRuleClasses.java#L682
which explains why there is no libfreetype.so in the apk.

Try doing System.loadLibrary for just libwrapper.so

And to get bazel build to work, you might just need the right set of command line flags which get implied by mobile-install

[XperielIndigo]

I'm only calling loadlibrary on libwrapper. The error is it wanting
libfreetype.

On Friday, August 7, 2015, ahumesky notifications@github.com wrote:

I see you have legacy_native_support = 0, which means that all of the
native libraries will be linked together into one .so:

https://github.com/google/bazel/blob/49543429f56cfe9c90562a1e9f9c66a9eabb5385/src/main/java/com/google/devtools/build/lib/rules/android/AndroidRuleClasses.java#L682
which explains why there is no libfreetype.so in the apk.

Try doing System.loadLibrary for just libwrapper.so

And to get bazel build to work, you might just need the right set of
command line flags which get implied by mobile-install

—
Reply to this email directly or view it on GitHub
#357 (comment).

[XperielIndigo]

Could the problem be legacy_native_support only combines all bazel generated .so files, without including source .so files, or without killing linking of source .so files (i.e. cc_library bar has source libfoo.so which means bar must be linked to foo in the final binary, but when legacy_native_support is added the requirement of linking libfoo.so is not killed, and perhaps the contents of libfoo.so is not added).

[ahumesky]

You could try setting legacy_native_support to 1. Or do you need it set to 0 for something?

My guess is that the .so being in srcs and/or it being behind a bind / http_archive is causing some problem. To test this, you could temporarily unzip the archive into your workspace and then depend on it as a regular part of your code. If that makes things work, then bind / http_archive is probably causing the problem. If that's still broken, then there's probably a bug with legacy_native_support.

[XperielIndigo]

I need legacy_native_support as I have conflicting library names. I'll try unzipping the archive.

[XperielIndigo]

Ok, I've tried unzipping the archive and depending on the inner rule and the same issue occurs. I believe it is using a .so as a source file. The rule is "freetype-cc" so the generated lib is "libfreetype-cc.so", the underlying lib is "libfreetype.so" and that is the one missing. I'm trying to get bazel build to work now.

[XperielIndigo]

When I compile with --cpu=armeabi-v7a it starts compiling and crashes with execvpe /bin/false failed --- No such file or directory on the first source file compilation.

[ahumesky]

I spent some time changing the bazel android example to a similar setup that you have, and I was able to reproduce the problem, and I couldn't get it to work with legacy_native_support set to 1 or 0, with and without the http_archive/bind, so it looks like the android rules just don't know how to properly handle a .so file being in the sources of a cc_library. While we figure that out, is it possible for you to compile the freetype library from source? You should still be able to put the source behind an http_archive rule.

Do you have /bin/false on your system? If you do then that sounds like another problem worth filing a bug about.

[XperielIndigo]

Well I'm pleased it isn't something crazy about my setup. I have a number of these types of artifacts which can't easily be compiled from source (many different compile flags/setups that would take some time to reproduce). I'll look into the /bin/false issue a bit more and I'm taking a look at the android linking problem in source now.

[XperielIndigo]

Any update on the progress? This is starting to get quite urgent for my project.

[ahumesky]

I've forwarded the issue to the person who wrote a lot of our android + cc support, but unfortunately I don't have an ETA for a fix

[XperielIndigo]

Do you have any idea where we might fix the problem yet? This is getting very tight for me now.

[programmablereya]

After some digging, I think I may have a fix for this. The key is that in modern native support mode, pre-compiled .so files are not added to the APK, even though they are used as input to the linker. Thus they're not available at runtime. Simply filtering these out and adding these to the APK should fix this; I'll write some tests first thing tomorrow and should be able to get this in soon. There's a chance I've misunderstood how things work and it will be more of a pain, but we'll find out soon enough!

[XperielIndigo]

Great, thanks Michael. I look forward to seeing it.

[XperielIndigo]

Any update Michael?

[programmablereya]

I've confirmed that my fix works; I should have it in Monday or Tuesday!

[XperielIndigo]

Hi Michael,

That may have fixed it, but now I'm getting an undefined symbol error at runtime for std::allocator<char>::allocator() (as mangled symbol _ZNSaIcEC1Ev). I would think this is just another error in my program, but it now occurs even when I'm not linking my primary library (i.e. just a basic c++ file that was compiling previously).

Any thoughts?

[ulfjack]

See #392 for the STL issue.