【问题标题】：is there a configure test that detects invalid symbolic links?是否有检测无效符号链接的配置测试？
【发布时间】：2013-10-21 16:28:50
【问题描述】：
我正在寻找https://trac.mpich.org/projects/mpich/ticket/1888 的解决方案。配置测试正确地找到了 libpciaccess.so，这是一个指向不存在的第二个符号链接而不是正确的符号链接的符号链接，因此所需共享对象的最终解析失败。
$ ll /usr/lib64/libpciaccess.so*
lrwxrwxrwx 1 root 22 2012-09-06 11:37 /usr/lib64/libpciaccess.so -> libpciaccess.so.0.10.2
lrwxrwxrwx 1 root 22 2012-04-05 12:25 /usr/lib64/libpciaccess.so.0 -> libpciaccess.so.0.10.8
-rwxr-xr-x 1 root 35K 2011-10-10 16:16 /usr/lib64/libpciaccess.so.0.10.8
有谁知道使用 configure 检查错误符号链接解析的好方法吗？
谢谢！
【问题讨论】：
标签：
symlink
configure
autoconf
【解决方案1】：
如果您使用AC_CHECK_LIB，配置测试会将测试程序链接到库。如果符号链接是孤立的，则该测试将失败。然而，由于这个包使用 pkg-config，AC_CHECK_LIB 几乎肯定不会被调用。这是PKG_CHECK_MODULES 的根本缺陷；配置脚本依赖于用户通过*.pc 文件提供的信息，但不验证该数据。这有点麻烦，我从未尝试过（因为我相信正确的解决方案是停止使用PKG_CHECK_MODULES），但您似乎可以简单地调用PKG_CHECK_MODULES 并立即附加到 LDFLAGS 然后调用AC_CHECK_LIB 验证标志。这至少会给配置脚本一个失败的机会，而不是让构建失败。
--编辑省略了以下咆哮，保留历史准确性，因为有时咆哮是一件好事，很难知道什么时候。--
试图通过允许通过--with-libname 标志添加特定库路径来破坏 autoconf 是注定要失败的策略。要搜索库的路径列表旨在由用户通过 LDFLAGS 指定到配置脚本，并且试图让链接器以不同的顺序选择搜索树中的各种库超出了 autoconf 的范围。
换句话说，看起来该用户在 0.10.2 版本之前的链接器搜索路径中安装了 0.10.8 版本，因此配置脚本非常正确地链接到 0.10.8 版本。包的维护者通过提供--with-libname 标志来欺骗用户，假装提供了比链接器允许的更多的功能。此外，用户通过提供不能准确反映系统状态的包配置文件对配置脚本撒谎，维护人员通过使用 PKG_CHECK_MODULES 鼓励这种谎言。这是为什么 pkg-config 不应与 automake 一起使用的另一个示例。当维护者不再对用户撒谎并且用户不再对配置脚本撒谎时，该错误就会消失。换句话说，用户需要按顺序获取他们的*.pc 文件，而维护者除了停止他们对pkg-config 的错误依赖外，无能为力。
为了进一步澄清，configure 脚本正确地确定了必要的库可用。但是，构建是由从用户的.pc 文件中获取的数据驱动的，配置脚本不会检查这些数据。这是由使用 PKG_CHECK_MODULES 造成的不匹配，并且是不鼓励包维护者使用 PKG_CHECK_MODULES 的一个重要原因。修复是让用户修复他们的.pc 文件。