应用错误收集

如果使用AC_CHECK_LIB，配置测试会将测试程序链接到库。如果符号链接是孤立的，则该测试将失败。但是，由于此程序包使用pkg-config，因此几乎肯定不会调用AC_CHECK_LIB。这是PKG_CHECK_MODULES的根本缺陷; configure脚本依赖于用户通过*.pc文件提供的信息，但未验证该数据。这有点像kludge，我从来没有尝试过（因为我相信正确的解决方案是停止使用PKG_CHECK_MODULES），但似乎你只需调用PKG_CHECK_MODULES并立即附加到LDFLAGS然后调用AC_CHECK_LIB来验证标志。这至少会使配置脚本失败，而不是让构建失败。

- 编辑以省略下面的咆哮，这是为了保持历史准确性，因为有时咆哮是好事，而且很难知道什么时候.--

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

换句话说，看起来这个用户在版本0.10.2之前的链接器搜索路径中安装了0.10.8版本，因此configure脚本非常正确地链接到0.10.8版本。包的维护者通过提供--with-libname标志来向用户说谎，这些标志假装提供比链接器允许的更多功能。此外，用户通过提供不能准确反映系统状态的软件包配置文件来欺骗配置脚本，维护者通过使用PKG_CHECK_MODULES来鼓励虚假。这是为什么pkg-config不应与automake一起使用的另一个例子。当维护者停止向用户说谎时，该错误将消失，并且用户停止对配置脚本撒谎。换句话说，用户需要按顺序获取他们的*.pc文件，除了停止他们对pkg-config

的错误依赖之外，维护人员无法帮助他们做任何事情。

为了进一步说明，configure脚本正确地确定了必要的库可用。但是，构建是由用户.pc文件中的数据驱动的，配置脚本未检查这些数据。这是由于使用PKG_CHECK_MODULES而产生的不匹配，并且是阻止软件包维护者使用PKG_CHECK_MODULES的重要原因。该修复程序是供用户修复其.pc文件。

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

1 个答案: