Search code examples
javaandroidc++android-ndkvs-android

VS-Android produces "wrong" names when linking to shared libraries

I'm using VS-Android to build my NDK program. I have two libraries, "bridge" and "utils", and the first one uses the second one. Both libraries compile succesfully and the files are named correctly as libbridge.so and libutils.so. However, when I try to load the files, I get an UnsatisfiedLinkError saying that libbridge.so cannot access liblibutils. Why is it trying to search for liblibutils?

Here's the Java code I use to load the libraries:

static
{
    System.loadLibrary("utils"); // This loads OK
    System.loadLibrary("bridge"); // This is found but causes the UnsatisfiedLinkError
}

The exact error I get is:

java.lang.UnsatisfiedLinkError: dlopen failed: could not load library "liblibutils"
needed by "libbridge.so"; caused by library "liblibutils" not found

Both library files are located in the same folder:

(projectfolder)/libs/armeabi-v7a/libbridge.so
(projectfolder)/libs/armeabi-v7a/libutils.so

Now, in Visual Studio, the relevant output of the linking phase of the libutils.so is this:

-o E:/NDKProject/Debug/armeabi-v7a/libutils.so -lc -lm -llog -lgcc -Wl,-soname,libutils

And the relevant output of the libbridge.so:

-o E:/NDKProject/Debug/armeabi-v7a/libbridge.so
-LE:/NDKProject/Debug/armeabi-v7a -lutils -lc -lm -llog -lgcc -Wl,-soname,libbridge

The project properties for the libutils.so is like this:

  • Target name: libutils
  • 'soname' Setting: $(TargetName)

And for the libbridge.so:

  • Target name: libbridge
  • 'soname' Setting: $(TargetName)
  • Additional Dependencies: -lutils

I'm baffled. Where does the extra "lib" come when the bridge library tries to use the utils library? The utils library does load succesfully, and so does the bridge library if I don't link the utils library and comment out all the calls to the stuff in the utils library.

So far, I've tried to change the target name to "utils" instead of "libutils", but it doesn't work. I've also tried to use lib$(TargetName) as the soname setting, but it doesn't work either.

Solution

  • I found the cause of the problem. Turned out that I was linking to a wrong file (wrong folder) where an old version of the utility library was located.