On: Strace – My Favourite Secret Weapon (2011)

[orivej]

Re. My Library Is Not Loading!, a pretty useful trick to find what files are missing is to extend your path env var with an empty directory and then grep strace output for its occurrences, e.g.

  mkdir /tmp/empty
  LD_LIBRARY_PATH+=:/tmp/empty  # or PATH, or PERL5LIB, etc.
  strace -f program |& grep /tmp/empty

I had a need to track what files are used by what processes spawned by a program (to infer dependencies between the processes), and it seemed (and probably was) simpler to use ptrace directly rather than to parse strace output, so I wrote https://github.com/orivej/fptrace/ . Soon it turned out useful to dump its data into shell scripts that reflect the tree of spawned processes and let you rerun an arbitrary subtree. I mostly use it to debug build systems, for example to trace configure and examine what env var affected a certain check in a strange way, or to trace make and rerun the C compiler with -dD -E to inspect an unexpected interference between includes.

[glandium → orivej]

If your only concern is libraries, you can ask the dynamic loader to print out what it loads:

LD_DEBUG=libs command

You can check out all the valid options with:

LD_DEBUG=help cat

or check out `man ld.so`.

On mac, there is something similar. Lookup all the DYLD_PRINT_* variables in `man dyld`.

[ereyes01 → orivej]

This is a cool trick. On Linux, the ldd command also tells you what libraries a program wants to link to. You can also play around with LD_LIBRARY_PATH to manipulate what ldd tells you.

[hugelgupf → ereyes01]

Binaries can also use dlopen to open libraries that aren't listed by ldd.

[ereyes01 → hugelgupf]

Good point, dlopen is fully run-time, and the strace approach will catch those too, so it's more comprehensive.

[v_lisivka → orivej]

IMHO,

  strace -e trace=file -f program

is much better in this case.