Teamo

我看懂了 po 说的啥了
简化一下，举个例子
用户即 server，好比每个人都有一个扩音器，每个人说的东西都可以到达其他人的耳朵中（ client ）
但是每个人都能选择听还是不听这个人说的内容。
问题是，要是有大量 bot 实行信息炸弹怎么办？
可信度几乎没有的公共信息最后都筛选不出来，会导致大量用户选择弃用吧
要不就是最后导致小圈子成立，这圈子可能产生大量非法信息
希望能给出解答

这个模块我有,驱动没试过 linux 哦

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

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

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

我猜是 windows 绘制以左上角为起点，然后 osx 以 entry 左上角为起点导致的。
然后就是系统主题会选择不同的宽度，所以导致有的宽，有的窄（窄的时候，上下就空间不够，标题栏占掉了下面按钮的空间）。

问题发现了
这个是 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

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

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

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

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