微信公众号搜"智元新知"关注
微信扫一扫可直接关注哦!

如果 ./configure 抱怨缺少头文件,你会怎么做

如何解决如果 ./configure 抱怨缺少头文件,你会怎么做

所以我最近在尝试使用 chromeos (chronos) 构建 a program 时遇到了问题。

我克隆了存储库并按照指示运行了 ./autogen.sh。目前没有问题。

但是,当我运行 ./configure 时,我收到以下消息:

checking arpa/inet.h usability... no

这告诉我配置脚本无法找到 arpa/inet.h文件,但是它没有告诉我它在哪里寻找。

鉴于常规 chrome 安装非常不寻常,我对出现某种错误并不感到惊讶,但该消息对于如何修复它根本没有帮助。

所以我的问题是:

  1. ./configure 是在寻找标题吗?
  2. 我是不是把它们放在某个找不到的地方?
  3. 如何让它找到它们?

解决方法

对于第一个问题,我查看了 configure 文件本身。这是一个 shell 脚本,所以我可以将最顶部的 append -x 替换为 #! /bin/sh 以使 shell 回显它运行的每个命令。

结果证明这是无法管理的,因为 configure 很大,而且函数之间有很多跳跃。所以我想知道那个神奇的 configure 脚本是什么,我之前运行的那个 ./autogen.sh 脚本是什么,我怎样才能让它以更详细的方式运行。原来 autogen 是一个由 autoconf 读取的描述,结果被写入一个 configure 文件。原来有一个 documentation page 解释了如何调试生成的脚本。

按照指示,我已将在 arpa/inet.h 脚本中检查 configure 的调用与 set -xset +x 包装在一起。

我在其中找不到任何 find 或任何类似内容,但我在这里和那里看到了一些 gcc -E test.c。我猜 autoconf 正在创建一个简单的 C 文件,其中包含一个 #include 指令,然后 autoconf 解析 gcc 的输出以判断标题是否可以找到了。

所以我的下一个测试是创建一个简单的测试文件来做到这一点:

#include <arpa/inet.h>

我将上述内容保存为 C 文件并尝试使用 gcc -E test.c > /dev/null 编译它。输出是这样的:

In file included from /usr/local/include/sys/socket.h:33,from /usr/local/include/netinet/in.h:23,from /usr/local/include/arpa/inet.h:22,from test.c:1:
/usr/local/include/bits/socket.h:390:10: fatal error: asm/socket.h: No such file or directory
  390 | #include <asm/socket.h>
      |          ^~~~~~~~~~~~~~
compilation terminated.

这告诉我 arpa/inet.h 的依赖项之一是导入 asm/socket.h 并且找不到它。

到达这里之后,我想确保 gcc 在继续之前在正确的位置寻找标题。幸运的是,文档中有一个 page 对此进行了解释。

跑步,

cpp -v /dev/null -o /dev/null

我在输出中获得了以下内容:

...
#include <...> search starts here:
 /usr/local/include
 /usr/include
End of search list.
...

/usr/local/include 确实是我的头文件所在的位置。回答第二个问题,不,我在其他地方没有 asm/socket.h。谷歌搜索我发现它应该包含在 linux 源头文件中,通常可以在分发包中找到。

当我使用 chromebrew 时,我需要运行 crew install linuxheaders 来获取它们。

这就是我回答第三个问题的方式。通过安装软件包,configure 能够运行并生成 make 文件,而我能够构建和安装 openfortivpn

希望这对将来的某个人(可能是我自己)有用。

,

./configure 是在寻找标头吗?

./configure 脚本调用编译器,编译器反过来搜索包含路径。编译器包含路径取决于系统和环境 - 请参阅您的编译器和系统文档。

大多数(如果不是全部)Linux 发行版都遵循 Filesystem Hierarchy Standard,其中系统 C 头文件位于 /usr/include 内,另外管理员 C 头文件安装在 /usr/local/include 中。很可能编译器添加了自己的自定义附加路径 - 对于 gcc 最重要的 C_INCLUDE_PATH 环境变量。

我是不是把它们放在某个找不到的地方?

即使您“拥有”它(文件本身),它也很可能与您的系统不兼容,并且符号在 C 标准库实现中不存在。最有可能的是,编译器已经被您的系统提供商配置为在系统中查找该文件,因此如果该文件不存在,很可能只是不存在。

我如何让它找到它们?

这是一个广泛的问题。如果系统不提供特定接口,则它很可能不存在。它有可能使用系统特定的工具或系统特定的包管理器进行安装。或者您可以编写自己的头文件提供的接口实现并提供接口并将您开发的头文件放入/usr/local/include

arpa/inet.hPOSIX specification 的一部分。您可以提供自己在标头中公开的符号的实现,并配置 ./configure 脚本以使用选项或环境变量找到它。

版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。