请指导我完成构建基本工具链所需的步骤,并讨论为什么应该按照您建议的方式进行。与构建交叉编译工具链的各种工具的文档的指针也非常感谢。然而,这些工具的文档只讨论实际使用这些工具来编译工具链,而不是它们如何以及为什么要这样做。通常,这些资源还提到其他工具会以不同的方式(当然更糟)进行操作,因此我有一种感觉,仅仅阅读源代码将帮助我了解给定构建工具的工作原理,而不是提供有关实际过程及其可能变化的洞察力。因此,我对自动化构建工具链的讨论不太感兴趣,而是对手动构建的有注释说明的指导感兴趣。同时请注意,我计划在同一台机器上构建和运行映像,因此我不需要进行交叉编译。但我仍然对交叉编译的讨论感兴趣,但重点可能应该放在其他方面。构建引导映像所需的其他内容不属于本问题-只是构建工具链以达到目的。
为了帮助您了解我的立场,以下是我提出的一些问题和我认为了解的一些事情: 我知道,即使在本地构建时,将用于构建映像的工具链与主机的工具链分开很重要,以避免链接到后来可能不可用的库(其他原因?)。我不知道是否足以相应地调整环境变量(哪些?),还是最好构建工具链,chroot并重新构建(从中获得什么?)。如果采用前者会出现什么问题?我已经阅读过两次构建gcc(使用第一个构建第二个)是过度的,因为它的构建系统会自动执行此操作。如果是这样,两个版本的构建有何区别,为什么这些区别很重要?如果两次构建不同,是否必然出现了问题,如果确实如此,该怎么处理呢?当进行交叉编译时,如果正确完成,是否会产生与本地构建完全相同的二进制文件?如果不是,为什么这并不是太糟糕的事情,许多项目仍然选择这种方式?
为了帮助您了解我的立场,以下是我提出的一些问题和我认为了解的一些事情: 我知道,即使在本地构建时,将用于构建映像的工具链与主机的工具链分开很重要,以避免链接到后来可能不可用的库(其他原因?)。我不知道是否足以相应地调整环境变量(哪些?),还是最好构建工具链,chroot并重新构建(从中获得什么?)。如果采用前者会出现什么问题?我已经阅读过两次构建gcc(使用第一个构建第二个)是过度的,因为它的构建系统会自动执行此操作。如果是这样,两个版本的构建有何区别,为什么这些区别很重要?如果两次构建不同,是否必然出现了问题,如果确实如此,该怎么处理呢?当进行交叉编译时,如果正确完成,是否会产生与本地构建完全相同的二进制文件?如果不是,为什么这并不是太糟糕的事情,许多项目仍然选择这种方式?