Linux 这个警告是什么意思？

我经常遇到来自gdb的以下警告：

警告：.XXX的动态节不在
预期地址

其中XXX是某个库的名称。

---

最近我是为libgobject-2.0.so买的。我的应用程序使用GTK。gdb一直在毫无问题地发布它，直到昨天我从存储库同步了最新的代码并重新构建它。从那以后，它一直在抱怨。动态部分。可能的原因是什么？我该如何解决这些问题呢？

一些gdb版本实际上对这个警告更有帮助。它们输出如下内容：

警告：“.libhello.so”的动态节不在预期地址（库错误或版本不匹配？）

确保GDB找到您的程序实际编译时使用的库，并且应用程序和库的任何调试符号（如果在单独的文件中）都是最新的，并且与您正在使用的版本一致

---

升级听起来像是一个很好的原因怀疑。预链接库也可能导致出现此警告，尽管我认为gdb可以处理这种情况。

我刚才也遇到了这个问题，它不可能是由thkala提到的引起的。。。现场调查如下

我有一个gdb在运行<代码>ps fax | grep-B1 jackdbus显示：

61747 pts/8    Sl+    0:00  |       \_ gdb
61764 pts/8    t      0:00  |           \_ /usr/src/jack2/pkg/jack2/usr/bin/jackdbus auto

在该gdb中，我在

main

上有一个断点（因此它从未真正运行过），但我确实运行了它（使用arg

auto

）来加载共享库，gdb打印：

warning: .dynamic section for "/usr/src/jack2/pkg/jack2/usr/lib/libjackserver.so.0" is not at the expected address (wrong library or version mismatch?)

除非jack2的构建系统出现了严重错误，否则这两个系统属于同一个系统（同时编译）

那么，是什么导致了这一警告呢？我的调查：

# cat /proc/61764/maps | grep 'jack'
555555554000-55555555a000 r--p 00000000 00:2f 33145                      /usr/src/jack2/pkg/jack2/usr/bin/jackdbus
55555555a000-555555566000 r-xp 00006000 00:2f 33145                      /usr/src/jack2/pkg/jack2/usr/bin/jackdbus
555555566000-55555556d000 r--p 00012000 00:2f 33145                      /usr/src/jack2/pkg/jack2/usr/bin/jackdbus
55555556e000-555555570000 r--p 00019000 00:2f 33145                      /usr/src/jack2/pkg/jack2/usr/bin/jackdbus
555555570000-555555571000 rw-p 0001b000 00:2f 33145                      /usr/src/jack2/pkg/jack2/usr/bin/jackdbus
7ffff7efe000-7ffff7f29000 r--p 00000000 fe:03 1976021                    /usr/lib/libjackserver.so.0.1.0
7ffff7f29000-7ffff7f72000 r-xp 0002b000 fe:03 1976021                    /usr/lib/libjackserver.so.0.1.0
7ffff7f72000-7ffff7f99000 r--p 00074000 fe:03 1976021                    /usr/lib/libjackserver.so.0.1.0
7ffff7f99000-7ffff7f9a000 ---p 0009b000 fe:03 1976021                    /usr/lib/libjackserver.so.0.1.0
7ffff7f9a000-7ffff7fa0000 r--p 0009b000 fe:03 1976021                    /usr/lib/libjackserver.so.0.1.0
7ffff7fa0000-7ffff7fa1000 rw-p 000a1000 fe:03 1976021                    /usr/lib/libjackserver.so.0.1.0

一鸣惊人。。。实际加载的共享库是

/usr/lib/libjackserver.so.0.1.0

gdb只是对实际加载的路径撒谎（这仍然是thkala提到的情况）

还要注意

info shared

的输出：

From                To                  Syms Read   Shared Object Library
0x00007ffff7f29040  0x00007ffff7f71ed3  Yes         /usr/src/jack2/pkg/jack2/usr/lib/libjackserver.so.0

该路径上的库确实有调试信息（但是

读取
下面缺少的
（*）
）表示
共享库缺少调试信息。
另一个指示是实际加载的库与此处显示的路径不相同

请注意，我设置了以下gdb变量：

(gdb) show sysroot
The current system root is "/nonexistent".
(gdb) show solib-search-path
The search path for loading non-absolute shared library symbol files is /usr/src/jack2/pkg/jack2/usr/lib:/usr/lib.

（有关原因，请参见页面上的
set solib search path
）

显然，设置
solib搜索路径
会影响gdb查找共享库的位置，但不会影响实际加载的共享库

因此，在下面的回答中，我还将
set-environment-LD\u-LIBRARY\u-PATH=/usr/src/jack2/pkg/jack2/usr/lib
添加到
/usr/src/jack2/.gdbinit
（我运行的地方是
gdb
；注意我的
~/.gdbinit
中有一行：
添加自动加载安全路径/usr/src/jack2
，以便实际加载它）。事实证明，我还可以简单地删除设置sysroot和solib搜索路径的行。完整的
.gdbinit
现在是：

cd /usr/src/jack2
directory src/jack2-1.9.14/linux
set environment LD_LIBRARY_PATH=/usr/src/jack2/pkg/jack2/usr/lib
file pkg/jack2/usr/bin/jackdbus
set args auto
b main
command 1
b JackLinuxFutex.cpp:137
b JackLinuxFutex.cpp:156
end
run

这就解决了问题。
这方面的一个典型案例是：T1）应用程序启动并使用旧的二进制文件保持运行，T2）然后二进制文件/符号在磁盘上“升级”（但应用程序未重新启动），T3）然后应用程序崩溃（或生成gcore）。通过查看升级的时间戳（T2）和coredump的时间戳（T3），可以假设使用了正确的（升级的）lib。错误的假设！提前知道这件事会救我一天。。。我们的应用程序正在使用一个定制的LD_库/etc启动环境，因此我们不得不在面对显而易见的问题之前用尽所有其他选项（IT人员只是忘记了在升级后重新启动应用程序）