0

I googled a lot without success.

What I need is, if possible, a way to retrieve runtime which dynamic libs are used by the process.

I know ldd, but I'm looking for a c coded solution.

The goal is to have processes that, at startup, retrieve info about libs and send them to an information process able to store and show all libs used by my processes.

EDIT Take notes that I'm developing an embedded system, that must be as little (in RootFS footprint terms) as possible.

LPs
  • 16,045
  • 8
  • 30
  • 61
  • See this: http://stackoverflow.com/questions/1519684/linux-gcc-ldd-functionality-from-inside-a-c-c-program – nnn Dec 01 '15 at 11:14
  • @nnn As far as I can understand is always something to be run on console, like using `system()` – LPs Dec 01 '15 at 11:21
  • Do you have a good reason why you don't want to use `ldd` or similar? – skyking Dec 01 '15 at 13:48
  • @skyking to avoid parsing the output of an external program and to avoid enlarging my RootFS with ldd. I missed to write that I'm talking about an embedded system. – LPs Dec 01 '15 at 13:51

2 Answers2

2

You want parse elf-header by your program. Ok, at the end you will got list of NEEDED dependencies for analyzed elf-file only, for example (readelf -d output):

 0x00000001 (NEEDED)     Shared library: [libcurl.so.4]
 0x00000001 (NEEDED)     Shared library: [libpthread.so.0]
 0x00000001 (NEEDED)     Shared library: [librt.so.1]
 0x00000001 (NEEDED)     Shared library: [libm.so.6]
 0x00000001 (NEEDED)     Shared library: [libc.so.6]

Then you should recursively parse each found library to get their dependencies. This forces to find full path for each library. For doing this you should handle search PATHs for libraries: built-in ld.so and environment variable LD_LIBRARY_PATH. There also can appear RPATH field (higher priority search path) in elf structure with special variables, for example:

0x0000000f (RPATH) Library rpath: [/usr/lib:/usr/lib/i386-linux-gnu:$ORIGIN]

ldd is bash script that has much routines and comments, so it can be stripped in minimal size if needed. In usual case it invokes the ld.so (standard dynamic linker) with set variable LD_TRACE_LOADED_OBJECTS. That is all. So parse ldd output is much comfortable.

SergA
  • 1,097
  • 13
  • 21
2

What ldd does is actually to set LD_TRACE_LOADED_OBJECTS environment variable and execute the program. So actually the ldd functionality doesn't require extra footprint to execute.

But you might want to avoid parsing the output. Or maybe you even use another dynamic linker than ld.so (which don't respect the LD_TRACE_LOADED_OBJECTS variable).

One solution would be to modify your dynamic linker so that it has an C API interface as well and allow it to report the .so files that would should have been loaded.

skyking
  • 13,817
  • 1
  • 35
  • 57