gcc 的搜索路径与 sysroot

编译条件里-I -L 跟指定的头文件和库文件的路径，c 和 cpp 头文件和动静态库环境变量分别为 C_INCLUDE_PATH，CPLUS_INCLUDE_PATH，LD_LIBRARY_PATH，LIBRARY_PATH

@MenghanKing 这个我都试过了，编译会出问题，只能设置一个路径。
**gcc --print-search-dirs 实际上有多个路径，不同的库路径也不一样。
问题是 sysroot 参数导致 gcc 不从自己的--print-search-dirs 那些路径去搜索了。

接上面，CPATH 等环境变量会导致多个不同目标的 gcc 都用同一个路径。
这个是很麻烦的大问题。

sysroot 不就是用来做交叉编译的时候指定目标机的头文件路径吗？就是为了方便不用写一堆-I 参数吧。

如果这个时候还去默认的路径去找，才应该奇怪的。你确定在默认路径找到的头文件能直接用？

"gcc 编译"指的是使用 gcc 交叉編譯還是編譯 gcc(bootstrap)用來交叉編譯?若是後者,without-headers 選項需要;若是前者,你的 gcc 安裝有問題.請注意閲讀 https://gcc.gnu.org/onlinedocs/gcc-8.3.0/gcc/Fixed-Headers.html#Fixed-Headers
它大概是講 gcc 包含預設頭文件及其原因和部分細節,由於英文水平有限無法幫你翻譯.

其他本人認爲有用的信息:
glibc 和 binutils 應該由同一個編譯器編譯而來.(確認是否安裝了多個版本的 glibc 和 binutls.)
一般的交叉編譯環境都是 chroot 進去用的,我相信知道 exherbo 都很少,遑論使用它的 multiarch.(最好用 chroot 的方式的 sdk).
osdevwiki https://wiki.osdev.org

这个问题主要归结于为什么 ubuntu 源的交叉编译的 gcc 和自己编译的或在树梅派提供的 gcc 的运行表现不一样。
显然 ubuntu 的 gcc 是正常的，按楼上的说法就是没问题，编译的程序就应该用编译工具自带的基础库。
sysroot 显然是提供额外的依赖库，而不是直接替换掉 gcc 的所有依赖库。

看样子只能对比各个 gcc 的编译参数然后看看到底是如何产生差异的。

1 楼说的没问题，-rpath 可以给默认搜索路径如果不设环境变量的话。建议贴出来具体的命令。

问题发现了
这个是 ubuntu 版 gcc 的搜索路径：
ignoring nonexistent directory "/home/t/rpi/sysroot/usr/local/include/arm-linux-gnueabihf"
#include "..." search starts here:
#include <...> search starts here:
/usr/lib/gcc-cross/arm-linux-gnueabihf/7/../../../../arm-linux-gnueabihf/include/c++/7
/usr/lib/gcc-cross/arm-linux-gnueabihf/7/../../../../arm-linux-gnueabihf/include/c++/7/arm-linux-gnueabihf
/usr/lib/gcc-cross/arm-linux-gnueabihf/7/../../../../arm-linux-gnueabihf/include/c++/7/backward
/usr/lib/gcc-cross/arm-linux-gnueabihf/7/include
/usr/lib/gcc-cross/arm-linux-gnueabihf/7/include-fixed
/usr/lib/gcc-cross/arm-linux-gnueabihf/7/../../../../arm-linux-gnueabihf/include
/home/t/rpi/sysroot/usr/include/arm-linux-gnueabihf
/home/t/rpi/sysroot/usr/include
这个是自己编译的 gcc 搜索路径：
ignoring nonexistent directory "/home/t/rpi/sysroot/home/t/x-tools/arm-unknown-linux-gnueabihf/arm-unknown-linux-gnueabihf/sysroot/include"
#include "..." search starts here:
#include <...> search starts here:
/home/t/x-tools/arm-unknown-linux-gnueabihf/lib/gcc/arm-unknown-linux-gnueabihf/8.3.0/../../../../arm-unknown-linux-gnueabihf/include/c++/8.3.0
/home/t/x-tools/arm-unknown-linux-gnueabihf/lib/gcc/arm-unknown-linux-gnueabihf/8.3.0/../../../../arm-unknown-linux-gnueabihf/include/c++/8.3.0/arm-unknown-linux-gnueabihf
/home/t/x-tools/arm-unknown-linux-gnueabihf/lib/gcc/arm-unknown-linux-gnueabihf/8.3.0/../../../../arm-unknown-linux-gnueabihf/include/c++/8.3.0/backward
/home/t/x-tools/arm-unknown-linux-gnueabihf/lib/gcc/arm-unknown-linux-gnueabihf/8.3.0/include
/home/t/x-tools/arm-unknown-linux-gnueabihf/lib/gcc/arm-unknown-linux-gnueabihf/8.3.0/include-fixed
/home/t/x-tools/arm-unknown-linux-gnueabihf/lib/gcc/arm-unknown-linux-gnueabihf/8.3.0/../../../../arm-unknown-linux-gnueabihf/include
/home/t/rpi/sysroot/usr/include
这两个都使用了 sysroot 参数到 /home/t/rpi/sysroot
官方版的多了倒数第二条的到 /usr/include/arm-linux-gnueabihf 的路径
这条路径是确实是 libc6 的位置，但 gcc 编译自带的是 /usr/include
也就是编译带了 sysroot 后，确实修改了 sysroot 到自定义的路径，gcc 不再用自己的库
但是自己编译的 gcc 因为没有这个倒数第二条的这条路径，所以没法正确的找到 libc6.deb 而对应的路径。

具体怎么设置出正确的路径，看来我要继续翻手册了，QAQ

接楼上，手动编译 gcc 时加个--includedir=/usr/(arm-liunx-gnuaebihf)/include
这样，新生成的 gcc 就会在我从 debian 上拉下来手动生成的 sysroot 中正确的找到 libc6 的头等文件了。

这个 arm-liunx-gnuaebihf 可能是与系统架构有关，显然 debian 的包有很多版本 cpu 运行。
不同的底层库又是要和 gcc 一起生成才能链接正常的程序，所以不能直接放 include 上，而自己编译的库只用于自己对应的 cpu 架构，所以就直接放 gcc 的 sysroot/usr/include 上了。

至于为什么要这样安排（以上是我推导的想法，可能不正确），希望有人能解答下 debian 包是如何管理和生成的。