Dalvik is looking for .so file with '.0' extension - why?

Question

I have started developing a very simple Android application that consists of three parts:

• the Java application itself
• a pre-built shared library (we'll call it libfoo)
• another shared library that uses the pre-built library (we'll call it libfoowrapper)

The file system looks something like this:

jni
Android.mk
libfoo.so
foowrapper.c

The Android.mk file contains the following contents:

LOCAL_PATH := $(call my-dir)

#==============================

include $(CLEAR_VARS)

LOCAL_MODULE := foo-prebuilt
LOCAL_SRC_FILES := libfoo.so

include $(PREBUILT_SHARED_LIBRARY)

#=========================

include $(CLEAR_VARS)

LOCAL_MODULE := foowrapper
LOCAL_SRC_FILES := foowrapper.c

LOCAL_SHARED_LIBRARIES := foo-prebuilt

include $(BUILD_SHARED_LIBRARY)

When I build the application in Eclipse, things seem to work fine - no errors are reported. However, when I upload the application to my Samsung Discover (running Android 4.0.4), I get the following error in the log:

03-05 21:20:27.859: E/AndroidRuntime(20324): Caused by: java.lang.UnsatisfiedLinkError: Cannot load library: link_image[1936]:   102 could not load needed library 'libfoo.so.0' for 'libfoowrapper.so' (load_library[1091]: Library 'libfoo.so.0' not found)

Why is the Dalvik looking for a .so.0 file instead of a .so file? What changes do I need to make to my app to get rid of this error?

Answer 1

At least in the Linux world, every shared library has a special name called the soname. The soname has the prefix lib, the name of the library, the phrase .so, followed by a period and a version number that is incremented whenever the interface changes (as a special exception, the lowest-level C libraries don't start with lib). A fully-qualified soname includes as a prefix the directory it's in; on a working system a fully-qualified soname is simply a symbolic link to the shared library's real name.

Every shared library also has a real name, which is the filename containing the actual library code. The real name adds to the soname a period, a minor number, another period, and the release number. The last period and release number are optional. The minor number and release number support configuration control by letting you know exactly what version(s) of the library are installed. Note that these numbers might not be the same as the numbers used to describe the library in documentation, although that does make things easier.

Reference: Linux Standard Base

Edit: It seems this is not an uncommon problem, haven't seen any real solutions to it, but perhaps this will get you started to finding something that works for you.

Problem with LOCAL_SRC_FILES when using PREBUILT_SHARED_LIBRARY https://groups.google.com/forum/#!topic/android-ndk/_UhNpRJlA1k

Creating non-versioned shared libraries for android http://www.opengis.ch/2011/11/23/creating-non-versioned-shared-libraries-for-android/

Library 'libproj.so.0' not found https://groups.google.com/forum/?fromgroups=#!topic/android-ndk/ai3tu0XXs88