2

I'm using the latest version of the NDK (as of a few weeks ago), r10d, and using the build tools to build python and some extensions in python. Using the build tools, I create a shared object that then gets linked into my project in Android Studio. In my build environment outside of Android studio, where I build the embedded Python library, I use the latest platform automatically, so in this case it is using NDK_ROOT/platforms/android-21.

All built fine, but then it crashed on a device running 4.4.4 with the error: java.lang.UnsatisfiedLinkError: dlopen failed: cannot locate symbol "epoll_create1" referenced by "libMyNativeIntfc.so"...

So, doing some research, I see that one of my python extensions uses this method, and it is defined in the NDK's sys/epoll.h. However, it was added to bionic in platform android-21 (I'm surprised I haven't encountered this already as I've been building since API 16). In previous platform libraries, the method is not exported. So I believe this method was just added to the latest android-21 libc (I verified it exists in the android-21 libc.a library and headers but not android-19 and below.

I'm looking for a bit of advice for the best way forward. As it stands, I think there are a couple of options. 1) Build against android-20 NDK platform instead, in which case my configure scripts will cull out the use of the method in my extension, and all will be happy. 2) Change the extension code to call epoll_create() instead, but I really would like to keep it the same as the upstream repo. 3) Link against the static libc.a in the android-21 usr/lib directory...now this one I'm a bit wary of. Would this be okay?

Thanks, Chris

reactive-core
  • 1,071
  • 1
  • 7
  • 15
  • Not really sure why you don't want to build against the versions of Android you intend to support (if you do not, you can find other issues where something changed from being a macro to a library function) but before trying to statically link libc (which sounds dubious if this is jni code), I'd consider writing my own wrapper to invoke this via syscall() using the the number macro - which was defined all the way back to the first NDK release. – Chris Stratton Apr 30 '15 at 19:44
  • I didn't say I didn't want to build against an older version of Android. That was option 1 of the 3. I was just looking for input on the best approach from those. I do agree with you about finding other incompatibilities, but on the other side of the coin, Google recommends always building against the latest NDK when you target the latest API, so I guess I should have said that was the only reason I didn't just go that route right away. I think you're right about the static linking...sounds bad. The macro sounds useful, I'll look into that. Thanks for the feedback! – reactive-core May 01 '15 at 00:57
  • 1
    In case of the NDK, the platforms are forward compatible, not the other way around. It's always best to use the latest NDK, but not with the highest platform, unless you're only targeting the latest version of Android. In general, `APP_PLATFORM` should be the same as your Android project's `minSdkVersion`. – ph0b May 06 '15 at 15:07
  • 1
    Thanks ph0b. I'm targeting the latest but my minimum is 15. I should use platform android-15 then it seems. This is something I wasn't aware of. Can you make your comment an answer? I'll accept it. Thanks! – reactive-core May 09 '15 at 14:38

0 Answers0