使用autotools获取所需的标头和库

时间:2017-11-28 11:10:11

标签: dependencies package dependency-management autotools autoconf

configure.ac可以包含对标题和库的检查:

AC_CHECK_LIB(cap,cap_compare,[cap_libs="-lcap"])
AC_CHECK_HEADERS([sys/acl.h linux/netlink.h])

因为有一个autotools支持只是为了简单地获取这些文件的列表(即使没有显示它们的默认位置或至少提供这些文件的位置):

/usr/include/sys/acl.h
/lib/x86_64-linux-gnu/libcap.so.2

我试图找到/创建工具,这些工具会从autotools输入生成的Linux发行版的缺失软件包。

更新我发现我没有正确表达自己并用错误的陈述误导你。我是LTP project的开发人员之一。我扩展了我们的autotools宏,所以我知道它是如何工作的。由于这个项目的目的是从源代码编译(在发行版中不会有一个包),我想让用户编译它以便为所有主要的Linux发行版提供它的包依赖关系列表。

手动维护这些依赖项可能是最简单的方法。但是因为我们以autotools AC_CHECK_LIB()AC_CHECK_HEADERS()宏的形式存在这些依赖关系,所以我想使用它。以某种方式输入自动工具(configure.ac和所有m4/*.m4)并生成标题和目录列表:

sys/acl.h
linux/netlink.h
...

libcap.so
...

此列表对我有很大帮助。这就是我想知道的。

当然,我可以手动创建这个列表,也可以使用正则表达式从autotools或源代码解析它,但从开箱即用的autotools中获取它会很好。

想法如何处理此列表:我还有另一个带有预定义包含路径和默认库路径的脚本(/usr/include/将包含大多数发行版添加的路径,例如{ {1}}用于Debian / Ubuntu或/lib/x86_64-linux-gnu/用于openSUSE)我放在头文件和库之前。恕我直言/usr/lib64不是一个选项,因为它的pkg-config配置文件安装了依赖项,所以当我搜索的软件包未安装时它将无法使用

然后我使用此列表搜索包,使用能够在线搜索的分发工具(即不依赖于正在安装的包,即*.pc用于Debian / Ubuntu,{ {1}},apt-filednf)或在线搜索(https://packages.qa.debian.org/,...),但这是另一个话题。

2 个答案:

答案 0 :(得分:0)

我将在此假设您不是configure.ac文件的所有者。 不幸的是,我不认为存在这样的工具。

根据William Pursell在this post中的回答,autotools不是软件包管理器,所以它对软件包本身一无所知,就像Linux发行版的软件包经理那样。

pkg-config为autotools带来了一些包的概念,但根据我之前链接的帖子,它给出的结果可能是错误的,特别是如果你考虑交叉编译。

但是,您仍然可以使用configure.ac中的pkg-config宏来尝试识别哪些软件包(您的操作系统和软件包管理器已知)丢失了。

关于AC_CHECK_LIBAC_CHECK_HEADERS,我认为您将很难使用它们来生成缺少的标头和库的绝对路径,原因如下:

  • 标头和库文件位置的前缀取决于分布(在Ubuntu 16.04上看到的历史/usr/lib对比较新的/usr/lib/x86_64-linux
  • 在分发本身(/usr/lib vs /usr/local/lib
  • 中也是如此
  • 某些操作系统软件包管理器不会为您提供给定软件包中包含的文件列表,除非该软件包实际上已经安装在您的系统上(在Ubuntu 16.04上就是apt的情况)
  • 包含给定库的包可能在不同的发行版上没有相同的名称(我记得在Ubuntu之后使用Fedora时遇到此问题,我无法找到我习惯使用的任何包)。

简而言之,我并不认为这样的工具存在(但可能是错误的),编写一个工具可能会显得非常复杂,并且与一个特定的操作系统/发行版密切相关。

答案 1 :(得分:0)

  

因为有一个autotools支持只是为了简单地获取这些文件的列表(即使没有显示它们的默认位置或至少提供这些文件的位置):

您似乎对Autoconf的运作方式存在误解。它没有具体知道在何处定位标头或库,当然也没有默认位置的概念。相反,它使用先前发现的编译器和链接器,以及在其标准变量中设置的任何标志,以检查头文件和库的存在。

编译器有a built-in search path for headers,链接器类似a built-in search path for libraries。这些内容可能会-I-L以及$CPPFLAGS$CFLAGS$LDFLAGS中的其他标记(如果适用)在执行检查。这些组合决定了搜索任何特定标题或库的位置,但同样不能直接由configure脚本本身进行搜索。

  

我正在尝试查找/创建工具,这些工具将来自autotools输入生成的Linux发行版的缺失软件包。

好吧,你当然可以解析Autoconf输入文件。事实上,因为它设计为通过m4进行处理,您可以编写一组替换的m4宏和配置,以提供AC_CHECK_HEADER的详细信息,{{1等等被调用的宏。您可以通过这种方式很好地了解构建程序包所需的库,而不是查找它们的特定目录。