Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

How to list library dependencies of a non-native binary?

When developing for native platform, I can use ldd to list all the shared libraries (.so files) a binary executable I build will try to load upon start-up. But when cross-compiling, I don't know how to get the same information. The ldd is not a normal binutils utility, like strip or ar, that can be built alongside gcc for cross compiling, but instead, it is a cryptic shell script that apparently can only run on native platform.

So, using the cross-target binutils tools, is there any way to get a list of the dynamically linked dependency for of a foreign binary?

like image 394
lvella Avatar asked Apr 07 '12 05:04

lvella


People also ask

How do I find library dependencies?

Use objdump -p libABCD.so | grep NEEDED to view dependencies on individual library files. Then follow on the output libraries. Show activity on this post. Instead of giving the boost libraries as -l on the linker command line, you can also give them with their full path and file name.

What are library dependencies?

Dependency on libraries. If a module or mediation module needs to use resources from a library or if a library needs to use resources from another library, you have to open the module or library with the dependency editor and add a dependency on the required library.


3 Answers

is there any way to get a list of the dynamically linked dependency for of a foreign binary

You can list direct dependencies of a binary easily enough:

readelf -d a.out | grep NEEDED   0x0000000000000001 (NEEDED)             Shared library: [librt.so.1]  0x0000000000000001 (NEEDED)             Shared library: [libc.so.6] 

I know of no way to recursively continue this to get the full list (as ldd does). You'll have to repeat the process for every NEEDED library by hand.

like image 179
Employed Russian Avatar answered Sep 20 '22 06:09

Employed Russian


You can do bash -x ldd /bin/ls to understand what ldd is doing. The ldd script is not that "cryptic". It basically runs

LD_TRACE_LOADED_OBJECTS=1 /lib64/ld-linux-x86-64.so.2 /bin/ls 

so it uses the dynamic loader of the system (because the result of ldd depends upon your actual environment and system!). But you could examine with objdump -x /bin/ls the dynamic section of an executable, e.g.

% objdump -x /bin/ls   /bin/ls:     file format elf64-x86-64   /bin/ls   architecture: i386:x86-64, flags 0x00000112:   EXEC_P, HAS_SYMS, D_PAGED   start address 0x00000000004046d4    Program Header:       PHDR off    0x0000000000000040 vaddr 0x0000000000400040 paddr 0x0000000000400040 align 2**3            filesz 0x00000000000001c0 memsz 0x00000000000001c0 flags r-x     INTERP off    0x0000000000000200 vaddr 0x0000000000400200 paddr 0x0000000000400200 align 2**0            filesz 0x000000000000001c memsz 0x000000000000001c flags r--       LOAD off    0x0000000000000000 vaddr 0x0000000000400000 paddr 0x0000000000400000 align 2**21            filesz 0x0000000000019ef4 memsz 0x0000000000019ef4 flags r-x       LOAD off    0x000000000001a000 vaddr 0x000000000061a000 paddr 0x000000000061a000 align 2**21            filesz 0x000000000000077c memsz 0x0000000000001500 flags rw-    DYNAMIC off    0x000000000001a028 vaddr 0x000000000061a028 paddr 0x000000000061a028 align 2**3            filesz 0x00000000000001d0 memsz 0x00000000000001d0 flags rw-       NOTE off    0x000000000000021c vaddr 0x000000000040021c paddr 0x000000000040021c align 2**2            filesz 0x0000000000000044 memsz 0x0000000000000044 flags r--   EH_FRAME off    0x0000000000017768 vaddr 0x0000000000417768 paddr 0x0000000000417768 align 2**2            filesz 0x00000000000006fc memsz 0x00000000000006fc flags r--      STACK off    0x0000000000000000 vaddr 0x0000000000000000 paddr 0x0000000000000000 align 2**3            filesz 0x0000000000000000 memsz 0x0000000000000000 flags rw-    Dynamic Section:     NEEDED               libselinux.so.1     NEEDED               librt.so.1     NEEDED               libacl.so.1     NEEDED               libc.so.6     INIT                 0x0000000000402148     FINI                 0x00000000004125f8     HASH                 0x0000000000400260     GNU_HASH             0x00000000004005c0     STRTAB               0x0000000000401100     SYMTAB               0x0000000000400620     STRSZ                0x00000000000004d7     SYMENT               0x0000000000000018     DEBUG                0x0000000000000000     PLTGOT               0x000000000061a208     PLTRELSZ             0x0000000000000990     PLTREL               0x0000000000000007     JMPREL               0x00000000004017b8     RELA                 0x0000000000401740     RELASZ               0x0000000000000078     RELAENT              0x0000000000000018     VERNEED              0x00000000004016c0     VERNEEDNUM           0x0000000000000003     VERSYM               0x00000000004015d8    Version References:     required from librt.so.1:       0x09691a75 0x00 05 GLIBC_2.2.5     required from libacl.so.1:       0x05822452 0x00 06 ACL_1.2       0x05822450 0x00 04 ACL_1.0     required from libc.so.6:       0x09691a75 0x00 03 GLIBC_2.2.5       0x0d696913 0x00 02 GLIBC_2.3 

Again, the actual dependency depends upon the system where your binary is run (e.g. because I could have an LD_LIBRARY_PATH with my own libc.so.6 somewhere, which would be a bad idea).

So you need a cross variant of objdump

like image 20
Basile Starynkevitch Avatar answered Sep 23 '22 06:09

Basile Starynkevitch


while in gdb, info shared is similar to ldd. It gives complete human readable runtime information of the executable.
readelf would miss path and other libraries information.
readelf is a very good tool for on the host study. Developer may choose that works.

like image 26
AjayKumarBasuthkar Avatar answered Sep 23 '22 06:09

AjayKumarBasuthkar