3

I copied libsonivox.so into /platforms/android-14/arch-arm/usr/lib/, my android.mk file is:

LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
LOCAL_MODULE    := midi
LOCAL_SRC_FILES := midi.c
LOCAL_LDLIBS    += -lsonivox
include $(BUILD_SHARED_LIBRARY)

but when I run ndk-build I get this error:

/home/sebastian/ndk/toolchains/arm-linux-androideabi-4.6/prebuilt/linux-x86_64/bin/../lib/gcc/arm-linux-androideabi/4.6/../../../../arm-linux-androideabi/bin/ld: error: cannot find -lsonivox

Any idea what I'm doing wrong? Thanks!

PS: this might look like a dup post, but I read every other post related to this topic, none of them helped

sebgar
  • 194
  • 3
  • 7
  • Is that the directory you are pulling your platform libs from? Are you sure? The absolute path "/platforms" doesn't seem to match the path for your ndk install itself "/home/sebastian/ndk". What about using a -L flag to specify the directory where it can be found. And why not just put it in your project directory rather than contaminate the ndk install with custom files? – Chris Stratton Apr 02 '14 at 03:22
  • For what I understood (which is not much, I'm just now learning NDK) libsonivox.so is already in all devices in the systems dir so the Android.mk is trying to create a link to that file. I'm following an example I found online which is similar to what I want ndk for. I missed a part of the path, /platform is inside the ndk directory – sebgar Apr 02 '14 at 03:26
  • Is libsonivox considered a public API or private? If private (as being on the device but not having a matching .a file in the ndk distribution suggests) then keep in mind you are strongly advised not to try to use it, as it's details may change without notice from device to device or build to build. – Chris Stratton Apr 02 '14 at 03:30
  • I will have to find out. Regardless, can you see why my code can't find it? – sebgar Apr 02 '14 at 03:38
  • Run ndk-build as `ndk-build V=1` for verbose mode to see which lib directory it is actually pulling from - or edit the whole output into your post. – Chris Stratton Apr 02 '14 at 03:56
  • I'll try that and get back to you. In the mean time, I copied hte library into every usr/lib folder in every android-xx and every arch-xxx and it kind of worked. It compiled successfully fro arm and armv7, but faild for x86. I guess I need 3 different versions of the library for arm, mips, and x86. – sebgar Apr 02 '14 at 13:39
  • _I guess I need 3 different versions_: no, you need all four of them: armeabi, armeabi-v7a, x86, and mips. – Alex Cohn Apr 02 '14 at 22:06
  • But there are only 3 directories: arch-arm, arch-mips, and arch-x86. How do you do with armeabi and armeabi-v7a? you put them both in the arch-arm dir? – sebgar Apr 03 '14 at 16:34
  • @ChrisStratton ndk-build V=1 showed me that it was looking for arm-v7 in android-18. This is really helpful. It failed at that point because I removed all the libsonivox from the ndk dir. I'm working on getting all 4 versions and putting them in the right dir. Hope that solves this. Thanks again! – sebgar Apr 03 '14 at 16:55

2 Answers2

2

please replace local_ldlibs with full path.

LOCAL_LDLIBS     := $(LOCAL_PATH)/jniLibs/lsonivox.so \\path to the lsonivox
bhavesh kaila
  • 761
  • 1
  • 5
  • 25
  • That might work, but my goal is to create a link to a system library, and not include the library myself. Thus the LOCAL_LDLIBS with the -l option – sebgar Apr 02 '14 at 13:41
  • But this is *not* a system library *of the ndk* so it really should be in your project folder. Otherwise it will break if you upgrade/reinstall the toolchain. – Chris Stratton Apr 02 '14 at 14:13
  • This is a good answer. By looking for `LOCAL_LDLIBS` outside the `platform`, you still do not mean that the library will be added to your APK or linked into your binary. Be prepared that NDK will issue a warning that a non-NDK library is linked this way. – Alex Cohn Apr 02 '14 at 22:09
  • I think the distinction here is that it is on the device already, but because it is not a public API it is not included in the NDK. So the project needs a copy to link against, but not to deploy. Of course that is risky because changes in the library details won't be accommodated. Packaging another copy might work (if it were explicitly loaded rather than the system version, assuming that isn't already loaded by zygote) but may just move the issue with changes to the interface between the library and its dependencies. – Chris Stratton Apr 03 '14 at 17:11
0

Yes, it appears to have some problem with your path. However, the preferred way to use any pre-built 3rd party library is to use the include $(PREBUILT_SHARED_LIBRARY) method.

As such, I suppose this is probably mostly a duplicate of:

NDK: How to include Prebuilt Shared Library Regardless of Architecture

Another really nice benefit of this method is that if the prebuilt library has any associated headers, you can set it up so that the NDK build system will propagate the include paths for you. It's super nice.

Community
  • 1
  • 1
Peter M
  • 1,918
  • 16
  • 24