我遵循指令here和here来构建一个工具链，该工具链可以在Windows上运行，并为Linux和不同的硬件平台编译应用程序。起初我尝试为i686-linux创建交叉编译器，以便在通用的Debian 8系统上进行测试。
Binutils和GCC编译得很好，但我被困在Glibc。它告诉我：
*** The GNU C library is currently not available for this platform.
我看到Sysprogs工具链使用的是Newlib而不是Glibc，但我没有找到任何解释，只是Newlib是嵌入式设备的不错选择。
这是否意味着Newlib实际上是Windows的唯一选择 - ＆gt; Linux并没有办法编译依赖于Glibc的软件？也许有“作弊”，比如从目标平台复制预制的Glibc或其他一些解决方法？
理论上，我甚至不需要在Windows上构建Glibc，我只需要为目标体系结构构建一些“Glibc兼容存根”，以便在编译目标平台和操作系统时进行链接（当然只是动态）。或者我完全错了，GCC无法链接到与GCC本身链接到的不同的C库？
或者我应该忘记它并接受这样一个事实：从Windows到GNU / Linux实现完全的Glibc和Linux内核兼容的C / C ++交叉编译是不可能的（而且，很可能，永远不可能）？
我将接受解释GCC和Glibc如何相关的答案，以及是否可以链接Glibc与GCC本身构建时使用的C库不同，并提供一些有关它为什么不可能的见解
答案 0 :(得分：1)
我猜你在构建glibc时正在使用--target当你真正需要使用--host时（这与newlib的配置方式不同 - 最好不要问为什么）。
说，glibc构建系统需要一个区分大小写的文件系统，因为它创建了foo.oS和foo.os等文件，这些文件是非常不同的。在像Windows这样的系统上，这意味着构建将被破坏并失败，因为foo.oS和foo.os引用了同一个文件。有一些补丁可以解决这个问题，但实际上你最好先启动一个虚拟机并在其中进行工具链构建。
注意：我不是说你需要VM来完成所有开发。你只需要VM来构建你在Windows下运行的交叉编译器。这将是canadian cross版本。
不是手动完成所有这些操作，请查看crosstool-ng。它处理/补丁/修复了人们在尝试创建交叉编译器时所犯的许多常见错误。