7

I have tried to use the ltrace. I tried to use the following command to profile the library.so file which is used by a program sampleapp, ltrace -c -T --library=library.so --output=out.txt ./SampleApp. But it shows the above error. But library.so is a debug build. So the symbol table should be there. I have tried to verify it with objdump --source library.so | grep CreateSocket(). It returns codes that uses that CreateSocket() function. Which means it contains a symbol table. Than why that error occurs?

Related post: measure CPU usage per second of a dynamically linked library

Community
  • 1
  • 1
Tahlil
  • 2,680
  • 6
  • 43
  • 84

1 Answers1

3

It depends on how the executable SampleApp was created. You will see that error if it was statically linked. ltrace only works for dynamically linked applications.

You can run ldd SampleApp to show the shared object dependencies. It is was dynamically linked and has a dependence to libc, the output of ldd will contain a line like this:

libc.so.6 => /usr/lib/libc.so.6 (0x00007fb24ac53000)

In that case, you can use the ltrace option --library=libc.so.6 and it should work. However, --library=libc.so will not match (you will not get an error, but no library call will be matched).

When statically linked, ldd SampleApp will instead show this output:

    not a dynamic executable

My guess that it is because of static linking could be wrong. The important point, however, is that if ltrace shows this error, you have to start the diagnosis at the executable itself (the binary) and how it was created (linker options), not at the shared library.

The question How does ltrace (library tracing tool) work? has some good references to understand more about the internals of the ltrace.

Philipp Claßen
  • 41,306
  • 31
  • 146
  • 239