我试过使用ltrace。我尝试使用以下命令来分析程序sampleapp，ltrace -c -T --library=library.so --output=out.txt ./SampleApp使用的library.so文件。但它显示了上述错误。但是library.so是一个调试版本。所以符号表应该在那里。我试图用objdump --source library.so | grep CreateSocket()验证它。它返回使用该CreateSocket（）函数的代码。这意味着它包含一个符号表。那个错误发生的原因呢？
相关文章：measure CPU usage per second of a dynamically linked library
答案 0 :(得分：1)
这取决于可执行文件SampleApp的创建方式。如果它是静态链接的，您将看到该错误。 ltrace仅适用于动态链接的应用程序。
您可以运行ldd SampleApp来显示共享对象依赖项。它是动态链接的，并且对libc有依赖性，ldd的输出将包含这样一行：
libc.so.6 => /usr/lib/libc.so.6 (0x00007fb24ac53000)
在这种情况下，您可以使用ltrace选项--library=libc.so.6，它应该可以使用。但是，--library=libc.so将不匹配（您不会收到错误，但不会匹配任何库调用。）
当静态链接时，ldd SampleApp将显示此输出：
not a dynamic executable
我的猜测是因为静态链接可能是错误的。 然而，重要的一点是，如果ltrace显示此错误，则必须在可执行文件本身（二进制文件）及其创建方式（链接器选项）开始诊断，而不是在共享库中。
问题How does ltrace (library tracing tool) work?有一些很好的参考，可以更多地了解ltrace的内部结构。