我正在尝试构建一个aarch 64交叉编译器来为我的Raspberry Pi 3B构建东西。我一直在使用一个有用的脚本来为我构建gcc(原始脚本,mine filled in-注意这包含了我正在使用的库的版本)。在构建glibc时,它可以:
...
make subdir=setjmp -C setjmp ..=../ subdir_lib
make subdir=signal -C signal ..=../ subdir_lib
make subdir=stdlib -C stdlib ..=../ subdir_lib
make subdir=stdio-common -C stdio-common ..=../ subdir_lib
……然后无限期地被绞死。我把这件事搁了一夜,但还是没有完成。make
似乎只是占用了一整个核心,偶尔会把内存还给操作系统,然后再占用一些。没有gcc
进程或任何东西正在运行。
因为似乎libc.so
最终还是被构建了,我尝试在GCC构建文件夹(build-gcc
)中手动运行make all
,但我得到了:
checking dynamic linker characteristics... configure: error: Link tests are not allowed after GCC_NO_EXECUTABLES.
不确定这是否相关。
这是怎么回事?如果你能帮忙的话,我将不胜感激。谢谢.
- 主机操作系统:阿蒂克斯Linux x64
- 主机gcc:13.1.1
- make:GNU make 4.4.1
1条答案
按热度按时间ttcibm8c1#
TL;DR这是旧版glibc Makefiles和Make v4.4+的一个问题,其中构建图会受到干扰,并且stdio-common会不断重新评估和重建。因此,要么降级make,要么升级glibc版本到一个更新得多的版本。
我在Buildroot和crosstools-NG中也遇到了这种情况。
修改glibc的Makefile,以便跟踪
stdio-common
的make:我可以在输出中看到以下内容,表明相同的构建被一遍又一遍地重新执行:
这是发生在subdir_lib,others和subdir_install规则访问stdio-common的时候,这就是为什么你会得到一个libc.so,因为这都是后期构建。
使用一个不那么冗长的输出,我们可以看到(对于stdio-common/others目标,一些文件被重新标记并强制重建):我有一些更多的信息,从stdio-common/others。看起来确实是为每个调用创建了.stmp和.st文件。
我在想为什么...
作为解决方案,这里有一个修改后的规则,它可以成功地构建所有内容,但是你必须让每个步骤先挂起一次(显然,步骤在重新运行时挂起):