是否有配置测试检测无效的符号链接？

Question

我在查找https://trac.mpich.org/projects/mpich/ticket/1888的分辨率。配置测试正确地找到libpciaccess.so，这是一个符号链接，指向不存在的第二个符号链接而不是正确的符号链接，因此所需共享对象的最终解析失败。

$会/usr/lib64/libpciaccess.so*

lrwxrwxrwx 1根部22 2012-09-06 11点37 /usr/lib64/libpciaccess.so - > libpciaccess.so.0.10.2

lrwxrwxrwx 1根部22 2012-04-05 12:25 /usr/lib64/libpciaccess.so.0 - > libpciaccess.so.0.10.8

-rwxr-XR-X 1根35K 2011- 10-10 16:16 /usr/lib64/libpciaccess.so.0.10.8

有谁知道使用configure检查坏符号链接分辨率的好方法吗？

谢谢！

Answer 1

如果使用AC_CHECK_LIB，配置测试会将测试程序链接到库。如果符号链接是孤立的，那么测试将失败。但是，由于该软件包使用pkg-config，因此AC_CHECK_LIB几乎肯定不会被调用。这是PKG_CHECK_MODULES的一个基本缺陷;配置脚本依赖于用户通过*.pc文件提供的信息，但不验证该数据。这是一个混乱，我从来没有尝试过（因为我相信正确的解决方案是停止使用PKG_CHECK_MODULES），但似乎你可以简单地调用PKG_CHECK_MODULES并立即追加到LDFLAGS，然后调用AC_CHECK_LIB来验证标志。这至少会给配置脚本一个失败的机会，而不是构建失败。

--edited，省略了后面的咆哮，这是保留历史准确性和因为有时咆哮是一件好事，而且很难知道什么时候.--

试图通过允许特定库路径颠覆的autoconf通过--with-libname标志添加标志是一种注定失败的策略。要搜索库的路径列表旨在由用户通过LDFLAGS指定给配置脚本，并尝试让链接器以不同顺序选择搜索树中的各种库，这超出了autoconf的范围。

换句话说，它看起来像这个用户的版本0.10.8安装在版本0.10.2之前的链接器的搜索路径中，所以配置脚本是相当正确地链接到0.10.8版本。包的维护者通过提供一个--with-libname标志来伪装提供比链接器允许的更多功能。另外，用户通过提供不能准确反映系统状态的软件包配置文件来欺骗配置脚本，而维护人员通过使用PKG_CHECK_MODULES来鼓励这种错误。这是为什么pkg-config不应与automake结合使用的又一个例子。当维护者停止对用户说谎时，该错误将消失，并且用户停止对配置脚本说谎。换句话说，用户需要得到以他们*.pc文件，并没有什么维护者可以帮忙超越而中止pkg-config自己放错地方的依赖

为了进一步澄清，该configure脚本正确地确定所需的库可用。但是，构建是由用户的.pc文件中取得的数据驱动的，而这些数据未由配置脚本检查。这是由于使用PKG_CHECK_MODULES而产生的不匹配，也是程序包维护者不应该使用PKG_CHECK_MODULES的一个重要原因。修复方法是让用户修复.pc文件。