交叉编译的根文件系统中未声明的变量答案

【问题标题】：Undeclared variable in a cross compiled root filesystem交叉编译的根文件系统中未声明的变量
【发布时间】：2019-11-03 04:35:25
【问题描述】：

所以我基本上是从头开始交叉编译 Linux 根文件系统。我能够使用一个非常基本的工具链从头开始交叉编译所有基本软件。以下是使用的一些软件的列表：

Binutils 2.32
Glibc 2.29
Linux 5.2.11
Coreutils 8.31
GCC 9.2.0
pkgconf 1.6.3
用于根文件系统的 Make、autoconf、zlib 等

在rootfs里面使用chroot我用gcc编译这个小程序：

#include <stdio.h>
#include <limits.h>

int main()
{
  printf("PATH_MAX=%u\n", PATH_MAX);
  return 0;
}

未完成并输出错误：

(chroot)$ gcc test.c -o test
test.c: In function 'main':
test.c:6:27: error: 'PATH_MAX' undeclared (first use in this function)
    6 |   printf("PATH_MAX=%u\n", PATH_MAX);
      |                           ^~~~~~~~
test.c:6:27: note: each undeclared identifier is reported only once for each function it appears in

但是limits.h 确实存在于 chroot 中。

/usr/lib/gcc/x86_64-linux-gnu/9.2.0/install-tools/include/limits.h
/usr/lib/gcc/x86_64-linux-gnu/9.2.0/include-fixed/limits.h
/usr/include/c++/9.2.0/tr1/limits.h
/usr/include/limits.h
/usr/include/linux/limits.h

最后，下面是 chroot 中 gcc 的路径（这不是工具链）：

COLLECT_GCC_OPTIONS='-E' '-v' '-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-linux-gnu/9.2.0/cc1 -E -quiet -v /dev/null -mtune=generic -march=x86-64
ignoring nonexistent directory "/usr/lib/gcc/x86_64-linux-gnu/9.2.0/../../../../x86_64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/x86_64-linux-gnu/9.2.0/include
 /usr/local/include
 /usr/lib/gcc/x86_64-linux-gnu/9.2.0/include-fixed
 /usr/include
End of search list.
# 1 "/dev/null"
# 1 "<built-in>"
# 1 "<command-line>"
# 31 "<command-line>"
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 32 "<command-line>" 2
# 1 "/dev/null"
COMPILER_PATH=/usr/lib/gcc/x86_64-linux-gnu/9.2.0/:/usr/lib/gcc/x86_64-linux-gnu/9.2.0/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/9.2.0/:/usr/lib/gcc/x86_64-linux-gnu/
LIBRARY_PATH=/usr/lib/gcc/x86_64-linux-gnu/9.2.0/:/usr/lib/gcc/x86_64-linux-gnu/9.2.0/../../../../lib/:/lib/../lib/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-linux-gnu/9.2.0/../../../:/lib/:/usr/lib/

话虽如此，发生了什么事？我已经多次查看了我的工具链和实际的根文件系统包，一切看起来都还不错。问题可能是什么？另外，我可以采取哪些调试步骤来帮助识别此问题以及未来的任何问题？

编辑：

为了添加有关此问题的更多上下文，之前我尝试编译最新的kmod，但也得到了'PATH_MAX' undeclared 错误：

make --no-print-directory all-recursive
Making all in .
  GEN      libkmod/libkmod.pc
  CC       tools/kmod.o
  CC       tools/lsmod.o
In file included from tools/kmod.c:26:
./shared/util.h:24:56: error: 'PATH_MAX' undeclared here (not in a function)
   24 | int alias_normalize(const char *alias, char buf[static PATH_MAX], size_t *len) _must_check_ __attribute__((nonnull(1,2)));
      |                                                        ^~~~~~~~

进入shared/util.h 有#include <limits.h> 解决它的唯一方法是使用#include <linux/limits.h>，它基本上解决了这个问题。然而，还有更大的事情正在发生。我不应该那样做。我想用一个更简单的例子来问这个问题，以便尽可能多地取出变量。我希望这能为我的问题带来更多背景信息。

【问题讨论】：

"/usr/include" 是您从头开始的工具链中包含搜索路径的一部分吗？ (chroot)$ gcc -v test.c -o test 显示什么？查看"#include <...> search starts here:" 行下方虽然"/usr/include" 通常是默认搜索路径的一部分，但您的从头开始的工具链 评论让我很担心。
见stackoverflow.com/questions/9449241/…，链接文章如：insanecoding.blogspot.com/2007/11/pathmax-simply-isnt.html
@DavidC.Rankin 它在编译程序时显示了这一点。 ``` #include <...> 搜索从这里开始： /usr/lib/gcc/x86_64-linux-gnu/9.2.0/include /usr/local/include /usr/lib/gcc/x86_64-linux-gnu /9.2.0/include-fixed /usr/include 搜索列表结束。 ```

标签： c linux gcc glibc chroot

【解决方案1】：

<limits.h> 是 C 标准库的一部分，所以你真的必须在某个地方拥有它，不知何故，如果不是内置在编译器中。 PATH_MAX 是 POSIX 扩展。如果由于某种原因您的交叉编译器没有启用必要的标志，您可以尝试使用

#define _POSIX_C_SOURCE 1
#include <limits.h>

如果仍然失败，则说明您没有安装目标系统头文件。

【讨论】：