获取导致 g++ 中链接器错误的文件
我正在构建一个二进制文件，它使用多个编译为 .so 文件的组件。我收到一系列链接器错误，这些错误指向哪个 .so 文件导致了这些错误，但是我可以获得有关哪些文件正在调用未定义函数的信息，或者是否可能获取有关调用未定义函数的源代码位置的信息？我发现寻找函数 esp 太乏味了，因为使用了很多重载和模板（这意味着在很多地方都有相同的名称）。在 Windows 中，它显示哪个 .o 文件导致了未定义的符号，但我陷入了 Linux 中的库级别。我在linux下使用g++。任何指针都会有用。
I am building a binary which uses multiple components which are compiled as .so files. I am getting a flurry of linker errors which point to which .so file caused them, but can I get information about which files are calling undefined functions or if possible source code locations where undefined functions are being called? I am finding it too tedious to hunt down the function esp since lot of overloading and templates are being used (which means same name in many places). In windows, it shows which .o file caused the undefined symbol, but am stuck at the level of libraries in linux. I use g++ in linux. Any pointer would be useful.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您询问“共享库中的哪个对象文件导致了错误”。
问题是，当共享库被链接时，所有目标文件都已“融合在一起”，并且不再作为单独的实体存在于共享库中，因此您的问题有些毫无意义。
也就是说，如果您进行调试构建（使用
-g标志），链接器会告诉您哪个源文件和行导致了问题，然后您可能会能够翻译成目标文件。如果不能（例如，因为问题符号在头文件中被引用），您可以向链接器寻求帮助：再次重建库，传递链接器
-y标志：将告诉您哪个对象引用
my_unresolved_symbol。注意：链接器在 C++“下方”运行，因此您必须将损坏的名称（例如
_Znw）传递给它。You are asking "which object file inside a shared library is causing the error".
The problem is that by the time that shared library has been linked, all object files have been "fused together", and no longer exist inside the shared library as separate entities, so your question is somewhat meaningless.
That said, if you do a debug build (with
-gflag), the linker will tell you which source file and line is causing the problem, which you then may be able to translate into the object file.If you can't (e.g. because the problem symbol is referenced in a header file), you can ask the linker for help: rebuild the library again, passing the linker
-yflag:will tell you which object(s) reference
my_unresolved_symbol.Note: linker operates "below" C++, so you must pass the mangled name, e.g.
_Znwto it.使用
ldd（打印共享库依赖项），您可以检查 so 的依赖关系以及它们是否已解决。使用
nm -Aa --demangle您可以获得 *.so 文件中使用或定义的符号列表，只要它们没有被删除。使用过的符号至少应该保留，以便您可以检查是否有一些未解析的符号。With
ldd(print shared library dependencies) you can check the dependencies of an so and if they are resolved or not.With the use of
nm -Aa --demangleyou can get a list of symbols used or defined in an *.so file, as long as they were not stripped away. The used symbols should at least remain, so that you can check if there are some unresolved symbols.