6

Is there a simple and efficient way to know that a given dynamically linked ELF is missing a required .so for it to run, all from the inside of a C/C++ program?

I need a program with somewhat similar functionality as ldd, without trying to execute the ELF to find out the (met/unmet) dependencies in the system. Perhaps asking the ld-linux.so utility via some library? (I'm a newbie in this part of linux =)

NOTE: reading the source code of ldd was not very helpful for my intentions: it seems that ldd is in fact forking another process and executing the program.

If it's not possible to know that a program has unmet dependencies without executing it, is there some way to, at least, quickly list the .so's required for that ELF all from within my program?

Thanks in advance =)

Paul Sweatte
  • 24,148
  • 7
  • 127
  • 265
royconejo
  • 2,213
  • 3
  • 24
  • 29
  • Do you have good reason why not just invoke ldd utility and parse its output? Under linux, such technique is widely used. – Juraj Oct 05 '09 at 12:25
  • I'd prefer not to call the shell to execute anything else than my own program.. besides, it's not very efficient to fork, start a shell, etc just to try if an executable will run by trial and error.. but yes, I suspect invoking ldd is a good standard choice. – royconejo Oct 06 '09 at 20:12
  • 1
    Sorry, this is a myth. Fork is not at all expensive nowadays and most exec*() calls does not use shell to run a binary. It is easily possible that you will kill more time by diving into ld-linux internals as compared to fork()/exec() overhead for all future invocations together. – Juraj Oct 08 '09 at 14:25

3 Answers3

8

As per ld.so(8), setting the environment variable LD_TRACE_LOADED_OBJECTS to a non-empty string will give ldd-like results (instead of executing the binary or library normally).

setenv("LD_TRACE_LOADED_OBJECTS", "1", 1);
FILE *ldd = popen("/lib/libz.so");
ephemient
  • 198,619
  • 38
  • 280
  • 391
  • yes, that will give exactly the same output than ldd (well, with perhaps setting an extra couple of envs more) in fact ldd is nothing else than your code.. but of course, this solution is the same as calling ldd that in turn will call your code.. I was looking for another solution, perhaps querying ld-linux.so in another, more direct way.. – royconejo Oct 06 '09 at 20:17
  • .. and without invoking a shell =) – royconejo Oct 06 '09 at 20:18
  • Without invoking a shell is easy -- just `fork` and `exec` (`pipe` first if you want output, and `fdopen` if you really want a `FILE *`) instead of `popen`. This is basically querying `ld-linux.so` without having to hard-code *which* `ld-linux.so`. – ephemient Oct 06 '09 at 22:15
1

Have you tried dlopen function? you can use this to load a dynamic library (or, for your case, to ckeck if a library can be loaded).

Having a list of needed libraries is more difficult, take a look to handle_dynamic function on readelf source

Jaime Soriano
  • 7,309
  • 2
  • 33
  • 45
  • that function is interesting, I can see the rpath and another parameters.. I'll investigate further, thanks – royconejo Oct 06 '09 at 20:23
-1

What about using ptrace() to trace all open() calls to find all what the program depends on (however, the output includes files,not only libraries).Or maybe filtering the output by the prefix in file name "/lib" helps.

6ziv
  • 1