0

I have a whole bunch of around 500 libraries each of them depending on one another(shared libraries)

The problem is one/few of them are failing to load due to a missing dependency library and I have no logs about which is failing due to what missing library. Due to the large number I cannot analyze it on y own with a hex editor. This scenario is from an android phone. So if I keep all of the .so libraries at one place, is there any way to write a script which analyzes each library for its dependencies and checks its existence in the given directory?

What approach should be followed to do this as AFAIK is possible to list shared libraries only of a dynamic executable using ldd.

Varun Chitre
  • 3,050
  • 4
  • 23
  • 33
  • 1
    I have to ask- why? The most complicated PC projects I can think of don't have 100s of libraries. I'm talking things that run on supercomputers. There is absolutely no reason for this. – Gabe Sechan Jul 07 '14 at 16:40
  • You should be able to run ldd on your binary as well as on shared libs files. I don't fully understand what you are asking. Perhaps question could be clarified. Are the 500 .so files on android phone or in SDK or on both? Is your problem really a building/linking problem? How do you invoke the library load (do you run an app?) and how do you know the problem is missing library? Hopefully you can explain in a bit more detail. – gaoithe Jul 16 '14 at 13:52

3 Answers3

5

I'm not entirely sure if I understood you correctly, but I hope my answer helps you anyway.

Normally any dynamic linked binary can be examined with "ldd". It basically shows you all libraries the dynamic linker had to load to in order to resolve all external symbols. This works on libraries, as well as on executables. If you use ldd's "-r" flag, ldd will try to resolve all external symbols, and it will report missing ones.

You can then easily feed the output of "ldd -r" to "grep" and check for missing symbols.

The bash script could then look like this:

find /lib /usr/lib /usr/local/lib -iname "*.so*" | while read lib_name; do
    if ldd -r "$lib_name" 2>&1 | grep -qF "undefined symbol: "; then
        echo "library \"$lib_name\" seems to be broken"
    fi
done

I just wrote this out of my head, might contain minor synax/typing errors.

As I said earlier, this will also work on executables, in case you need it.

In case you need to extend your library search path, you can use the environment variable "LD_LIBRARY_PATH" for that. Just do:

export LD_LIBRARY_PATH=/path/to/my/libs

Since you specifically stated, that ldd will "only" work on dynamic libraries: Well, a statically linked binary (lib or exe), has no dependencies on other binaries (except for the linux kernel). So I'm not sure what you are looking for in this case ... ?

SIGSEGV
  • 412
  • 4
  • 5
1

ldd works for .so files as well

Try: 

cd /usr/lib   
ldd *

that will list all dynamic .so files used by the libraries, tries to resolv them, and show you anything that's missing.

DThought
  • 1,340
  • 7
  • 18
0

Remove

<uses-library android:name="org.apache.commons.lang"/>

This is only for Android Project Libraries not a plain old Jar file. Jar files will have their classes extracted and put into your apk by just including them in the build path.

Baptiste Wicht
  • 7,472
  • 7
  • 45
  • 110
Vaishali Sutariya
  • 5,093
  • 30
  • 32