我是 Autotools 的新手，目前正在尝试创建一个 configure.ac 文件，以便为以后安装我的程序检查多个依赖项。
现在，我想检查某些库是否存在，我发现使用 AC_CHECK_LIB 可以解决问题。我认为 PCK_CHECK_MODULES 也可以提供帮助，但我想坚持前者，除非 PCK_CHECK_MODULES 解决了我的问题：
AC_CHECK_LIB 执行预期的操作，即查找库并在找到时执行一项操作，如果未找到则执行另一项操作，但是，我的问题是：
如果 AC_CHECK_LIB 找到我的库，我怎样才能获得这个库的确切路径？也就是说，如果我的 AC_CHECK_LIB 是：
AC_CHECK_LIB (foo, function, [action-if-found], [action-if-not-found])
如果找到这个 foo 库，我有什么方法可以得到 exact 路径吗？
谢谢，
【问题讨论】：
如果 AC_CHECK_LIB 找到我的库，我怎样才能获得这个库的确切路径？
AC_CHECK_LIB 不提供任何机制让您可以这样做。它本身并不能确定实际位置。根据its documentation，它实际上是这样做的：
通过尝试链接测试来测试库
library是否可用 使用库调用函数function的程序。function应该 是库提供的函数。
当AC_CHECK_LIB 成功时，它只知道链接器找到了与给定库名对应的库，该库提供了具有指定函数名的函数。它不知道链接器在哪里找到它。另一方面，当那个宏没有找到一个库时，这并不一定意味着它不可用，而是链接器没有发现它受链接选项（如果有的话）有效那时。
请注意，这对于许多用途来说都非常令人满意。只有当您想使用它来定位其他相关资源时，您才需要知道实际位置。 configure 很少能在没有帮助的情况下找到图书馆，但需要额外的信息才能找到相关资源。
【讨论】：
echo "$(ldconfig -p | grep foo | tr ' ' '\n' | grep /)" 如果被 ldconfig 找到，它将返回该库的路径，但它不是很优雅，我相信它不适用于静态的。我的问题由此而来。
ldconfig 及其输出与在构建时查找共享库没有直接关系。无论如何，我怀疑您在这里遇到了 X-Y 问题。如果您需要与共享库相关的其他东西的位置，那么您最好添加一个变量（AC_ARG_VAR）或选项（AC_ARG_WITH），通过它可以将其位置传达给configure，并在不使用该机制时搜索一些标准位置。