在不指定 --prefix 或其他安装位置选项的情况下进行配置,默认情况下会在 /usr/local/lib 中安装新的 libpcap。大概您要覆盖的旧版本是系统 CentOS 版本,/usr/lib 中也是如此。
因此,链接器似乎在 /usr/local/lib 之前搜索 /usr/lib。
您可以通过将 -Wl,-Map,foo.map 添加到链接您的应用程序的 GCC 命令中,并将生成的 foo.map 文件中的 libpcap grepping 来准确查看正在链接的 libpcap。
您可以通过查看 (both of) 的输出来查看链接器正在使用的库搜索路径
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 如果这是该库的现有版本所在的位置。
您可以通过在构建 libpcap 时将 --prefix=/usr 添加到配置命令来实现此目的。在那里安装新的 libpcap 后,您应该能够编译并链接您的应用程序,而无需任何额外的链接器选项。
但是这会干扰包管理,因此在通过包管理器更新时会导致其他问题。所以你可能想先卸载系统 libpcap 包,或者一般寻找正确的方法来替换 CentOS 上的系统包。