在尝试使用 gdb 为使用 libtool 构建的包调试测试程序时，我看到了一个奇怪的问题。如果我运行libtool --mode=execute gdb .libs/libfoo.so并要求它列出某个函数list Bar::Baz的源代码，我会按预期获得源代码。如果我运行libtool --mode=execute gdb binary，我可以闯入Bar::Baz()，并在堆栈跟踪中查看它的参数，但我没有得到源文件或行号，如下所示：
#7 0x018348e5 in Bar::Baz(Qux*, Quux*) () from /path/to/libfoo.so
^^^^^^^^^^^ <--- debug symbols are present!
list Bar::Baz同样，如果我在调试可执行文件时尝试，我会得到
No line number known for 'Bar::Baz'.
我已经确认二进制文件与 链接-g，并且我可以列出它的main功能，所以我知道存在一些调试信息。
当我说 时info sources，我得到了构建库的文件的完整列表，以及正确的绝对路径。当我说 时info shared，我得到了目标文件的正确路径，列中有Yes一个Syms。
任何进一步的想法可能会出现什么问题，以及如何解决它？
编辑 1： 意外地，我在objdump -g有问题的库上运行，并得到以下输出：
/path/to/foo.so.0.0.0: file format elf32-i386
objdump: /path/to/foo.so.0.0.0: no recognized debugging information
这令人惊讶，因为objdump -h（我试图运行的）列出了一堆.debug_*部分。该objdump手册也提出readelf -w了建议，这似乎打印了大量信息。不过，我需要查看它实际提供的功能。
编辑2：所以，readelf -w产生了一些启示。无论出于何种原因，共享对象文件似乎都不包含来自绝大多数 链接到它的任何对象的调试信息。根据 Makefile，实际将对象收集到共享库中的命令可能未通过-g，因此信息未正确传播。有趣的是，这在我们所有其他配置上都有效（具有完整的调试信息），包括 x86_64 上的相同编译器版本（相对于目前的 x86）。
编辑 3：实际上通过在 LDFLAGS 上添加了 -g 的修改后的 Makefile 进行了完全重建，并且没有任何区别。现在我很好，真的很困惑。