默认情况下,未指定或其他安装位置选项的配置将在/usr/local/lib--prefix
中安装新的 libpcap 。大概您要覆盖的旧版本是系统 CentOS 版本,因此在/usr/lib中也是如此。
因此,链接器似乎在/usr/local/ lib之前搜索/usr/ lib 。
您可以通过添加-Wl,-Map,foo.map
到链接您的应用程序的 GCC 命令,并将生成的foo.map文件中的libpcap
.
您可以通过查看(两者)的输出来查看链接器正在使用的库搜索路径
gcc -print-search-dirs | grep ^libraries
ld --verbose | grep SEARCH_DIR
如果/usr/lib出现在/usr/local/lib之前,您可以添加-L/usr/local/lib
到您的链接命令以重新排序它们并选择您的新库。但这确实是一个hack。
所有这些都是针对链接时出现问题的情况。根据此共享库的版本控制方式,真正的问题可能会在您运行应用程序时、在动态链接期间发生。或者两者兼而有之。
当您在应用程序上运行 ldd 时,您看到列出的 libpcap 路径是什么?当你用 构建你的应用程序时-L/usr/local/lib
呢?
ldd yourapp
要强制动态链接器在/usr/local/lib中找到您的共享库,您可能需要查看链接器的-rpath
选项或LD_LIBRARY_PATH
环境变量。添加-L/usr/local/lib -Wl,-rpath,/usr/local/lib
到您的链接命令肯定会确保您使用新版本的库。但是,两者-rpath
都LD_LIBRARY_PATH
更像是一种黑客行为,如果您在没有仔细考虑的情况下尝试将应用程序二进制文件提供给其他人,则会引入其他问题。
所有这一切的非黑客方法是确保您将新的共享库安装到系统已知的目录中。这可能意味着/usr/lib如果这是库的现有版本所在的位置。
您可以通过--prefix=/usr
在构建 libpcap 时添加到 configure 命令来做到这一点。在那里安装新的 libpcap 后,您应该能够编译并链接您的应用程序,而无需任何额外的链接器选项。
但是,这会干扰包管理,因此在通过包管理器更新时会导致其他问题。所以你可能想先卸载系统 libpcap 包,或者一般来说寻找正确的方法来替换 CentOS 上的系统包。