9

Recently I upgraded the NDK and now my app crashes with missing symbol mkfifo:

E/dalvikvm(2031): dlopen("/data/app-lib/...mylib.so") failed: Cannot load library: soinfo_relocate(linker.cpp:975): cannot locate symbol "mkfifo" referenced by "mylib.so"...

The older platforms mkfifo was defined inline in sys/stat.h

static __inline__ int mkfifo(const char *__p, mode_t __m) {
    return mknod(__p, (__m & ~S_IFMT) | S_IFIFO, (dev_t)0);
}

But in platform version 21 it was changed to just an extern decleration:

extern int mkfifo(const char*, mode_t);

So that explains the missing symbol exception... my question is how do I fix it?

Iftah
  • 9,512
  • 2
  • 33
  • 45
  • If you have everything set up properly, that looks like a possible ndk bug. You may need to either build against the older ndk platform, or copy the old implementation into your project. Also check the android issues tracker and consider reporting it if it isn't already there. – Chris Stratton Nov 23 '14 at 16:42
  • [Weak symbols](http://en.wikipedia.org/wiki/Weak_symbol) should be able to resolve this issue. But I'm not convinced they work on Android, even though Android defines `__GXX_WEAK__` in the preprocessor. See [Different behavior of override weak function in shared library between OS X and Android](http://stackoverflow.com/q/20196368/608639) and [Does Android support weak symbols?](http://stackoverflow.com/q/27935228/608639). – jww Jan 14 '15 at 05:06
  • I see the same, but on rand() symbol both on 32bit and 64bit version of NDK for linux. – Bram Jun 08 '15 at 19:42

2 Answers2

26

This happens if you build against the android-21 platform headers. Set APP_PLATFORM in jni/Application.mk to an older version, to build using the old headers, to make sure you only link to functions available earlier.

(Before android-21, the C library features and headers didn't really change significantly, so for the normal C library functions, it doesn't matter if you build targeting android-3 or android-20.)

This has been reported and is intentional behavior, see e.g. https://code.google.com/p/android/issues/detail?id=73725.

If you don't need to use new features from android-21, just build using older headers. (It doesn't matter that you're targeting an older platform version if you want to try to build for e.g. arm64-v8a or x86_64 that didn't exist before; ndk-build would build the 32 bit parts using the older target, and the 64 bit ones using the oldest target that supports them.)

In case you want to try to use new features from the android-21 platform conditionally if running on such a platform, you probably need to use dlopen and dlsym to load it conditionally anyway, so then you need to duplicate the other definitions from the new headers as well, to allow you to build using the older platform headers.

mstorsjo
  • 12,983
  • 2
  • 39
  • 62
  • 2
    Setting `APP_PLATFORM=android-19` worked for me. Thanks! – Iftah Nov 24 '14 at 09:41
  • 2
    how to set APP_PLATFORM in android studio? – Raneez Ahmed Feb 29 '16 at 08:07
  • Unless you're using the experimental NDK-supporting gradle plugin, which cannot be the case, because it doesn't work with .mk files, jni files won't be visible in the Android perspective if the Project view. Switch to Project or Project Files in order to view all the files. – Ivan Bratoev Aug 15 '16 at 12:59
9

I've tried mstorsjo's fix and it seems to work, however I was a bit concerned that from the link he posted it seems that Google doesn't really think this is a good idea. As a result I did a bit more digging and it seems like the 'proper' fix is to ship multiple APKs, with (at least) one targeting android-20 and below, and another targeting android-21 and above.

The problem arises from a change in the NDK to force the use of the 'fPIE' option when performing an NDK build. From the NDK 10d release notes:

Introduced the requirement, starting from API level 21, to use -fPIE -pie when building. In API levels 16 and higher, ndk-build uses PIE when building. This change has a number of implications, which are discussed in Developer Preview Issue 888. These implications do not apply to shared libraries.

If you look at the Developer Preview Issue 888, it states the following:

Bionic commit 76e289c026f and its predecessor, 2aebf5429bb, require all dynamically linked native executables to be built with -fPIE -pie. This has a number of possibly-unintended side effects, including:

  • Old/unmaintained apps that worked correctly under KitKat may now fail to run under "L". This could affect even simple apps that do not use the network, handle untrusted data, or target the new "L" SDK API.

  • Actively maintained apps that wish to target "L" must ship PIE executables or static executables. If an app wants to target ICS or below, it must also ship non-PIE executables or static executables. Even a simple "Hello world" program built with -fPIE -pie will segfault on ICS and GB.

Obviously you may prefer to go with the previous solution but just thought it was worth noting.

Community
  • 1
  • 1
  • 1
    (A bit late reply as I saw your answer only now) I'm not sure what you refer to in Google's reply as not thinking it's a good idea; the thing that is not a good idea is to run on older versions than the platform used during the build (contrary to the java side where you can easily build using a later target SDK). The issue you refer to about PIE is another, unrelated issue that came at 5.0 though, but it only affects a minority of apps (those apps that build executables, launched via `Runtime.exec()` or similar), not only libraries as is the default. – mstorsjo Mar 16 '16 at 18:46