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
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With