Created attachment 9531 [details] defconfig I only want to build a toolchain with a rust compiler so I have the following defconfig: BR2_x86_64=y BR2_KERNEL_HEADERS_5_4=y BR2_GCC_VERSION_12_X=y BR2_TOOLCHAIN_BUILDROOT_CXX=y BR2_PRIMARY_SITE="<internal mirror populated with "make sources">" BR2_INIT_NONE=y # BR2_TARGET_ENABLE_ROOT_LOGIN is not set # BR2_PACKAGE_BUSYBOX is not set BR2_PACKAGE_LIBBSD=y BR2_PACKAGE_HOST_ENVIRONMENT_SETUP=y BR2_PACKAGE_HOST_RUSTC=y BR2_PACKAGE_HOST_RUST=y The compilation of rust (host-rust-1.67.0) is not working. It fails with the following message when I call the "make" command: [ 7%] Building CXX object lib/Support/CMakeFiles/LLVMSupport.dir/RWMutex.cpp.o In file included from build/host-rust-1.67.0/src/llvm-project/llvm/lib/Support/Process.cpp:107: build/host-rust-1.67.0/src/llvm-project/llvm/lib/Support/Unix/Process.inc: In static member function ‘static size_t llvm::sys::Process::GetMallocUsage()’: build/host-rust-1.67.0/src/llvm-project/llvm/lib/Support/Unix/Process.inc:92:20: error: aggregate ‘llvm::sys::Process::GetMallocUsage()::mallinfo2 mi’ has incomplete type and cannot be defined 92 | struct mallinfo2 mi; | ^~ build/host-rust-1.67.0/src/llvm-project/llvm/lib/Support/Unix/Process.inc:93:10: error: ‘::mallinfo2’ has not been declared 93 | mi = ::mallinfo2(); | ^~~~~~~~~ build/host-rust-1.67.0/src/llvm-project/llvm/lib/Support/Unix/Process.inc: In static member function ‘static unsigned int llvm::sys::Process::GetRandomNumber()’: build/host-rust-1.67.0/src/llvm-project/llvm/lib/Support/Unix/Process.inc:455:10: error: ‘arc4random’ was not declared in this scope; did you mean ‘srandom’? 455 | return arc4random(); | ^~~~~~~~~~ | srandom [ 7%] Building CXX object lib/Support/CMakeFiles/LLVMSupport.dir/ThreadLocal.cpp.o [ 7%] Building CXX object lib/Support/CMakeFiles/LLVMSupport.dir/Signals.cpp.o gmake[4]: *** [lib/Support/CMakeFiles/LLVMSupport.dir/build.make:1902: lib/Support/CMakeFiles/LLVMSupport.dir/Process.cpp.o] Error 1 gmake[4]: *** Waiting for unfinished jobs.... gmake[4]: Leaving directory 'build/host-rust-1.67.0/build/x86_64-unknown-linux-gnu/llvm/build' gmake[3]: *** [CMakeFiles/Makefile2:7354: lib/Support/CMakeFiles/LLVMSupport.dir/all] Error 2 gmake[3]: Leaving directory 'build/host-rust-1.67.0/build/x86_64-unknown-linux-gnu/llvm/build' gmake[2]: *** [Makefile:171: all] Error 2 gmake[2]: Leaving directory 'build/host-rust-1.67.0/build/x86_64-unknown-linux-gnu/llvm/build' thread 'main' panicked at ' command did not execute successfully, got: exit status: 2 I confirm that the CMake of LLVM detects both arc4random and mallinfo2 features, inside build/host-rust-1.67.0/build/x86_64-unknown-linux-gnu/llvm/build/CMakeCache.txt, I have the following: //Have symbol arc4random HAVE_DECL_ARC4RANDOM:INTERNAL=1 and //Have symbol mallinfo2 HAVE_MALLINFO2:INTERNAL=1 For information, when I try to build the vanilla rustc 1.67.0 (from github) directly with the toolchain of my system (gcc 10.2.1, Debian 11), the two "features" are not detected by CMake and the compilation works. But when I copy the config.toml generated by rust.mk into the vanilla rust sources, the compilation is failling with the same error: I am able to reproduce the problem with the vanilla sources. I managed to implement a workaround with the following patch applied on buildroot's sources: diff --git a/package/rust/rust.mk b/package/rust/rust.mk index d14ad3a3e7..d11a39e4a5 100644 --- a/package/rust/rust.mk +++ b/package/rust/rust.mk @@ -60,8 +60,6 @@ define HOST_RUST_CONFIGURE_CMDS echo '[rust]'; \ echo 'channel = "stable"'; \ echo 'musl-root = "$(STAGING_DIR)"' ; \ - echo '[target.$(RUSTC_TARGET_NAME)]'; \ - echo 'cc = "$(TARGET_CROSS)gcc"'; \ echo '[llvm]'; \ echo 'ninja = false'; \ ) > $(@D)/config.toml I am suprised to see here that the cross-compiler was defined as cc in the generated config.toml, as we want to build a rust compiler which can be executed on the host system, not on the target system.
Created attachment 9536 [details] Possible workaround
> I am suprised to see here that the cross-compiler was defined as cc in the generated config.toml, as we want to build a rust compiler which can be executed on the host system, not on the target system. To give an answer to my question: we need to give the cross-compiler compiler in the cc attribute of config.toml. As this compiler will be used to compile the "shims" written in C which will run on the target. Can somebody confirm it ? Would be a solution to replace the "unknown" in RUSTC_TARGET_NAME value (set in rustc.mk) by the value of BR2_TOOLCHAIN_BUILDROOT_VENDOR ? With a different vendor string, the rustc's bootstrap program would be able to make the difference between the host and the target toolchains, even if the triplets are the same. I wrote a patch which implement this solution. But the drawback seem to be that the rust-bin package could only be used as stage0 now.
Created attachment 9546 [details] Use the toolchain's vendor string to identify the rustc target.
(In reply to alban.at.ifd from comment #3) This patch doesn't work as the x86_64-buildroot-linux-gnu is not recognized by the (stage0 ?) rustc. I get the following: Finished release [optimized] target(s) in 11m 23s Copying stage0 rustc from stage0 (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu / x86_64-unknown-linux-gnu) Assembling stage1 compiler (x86_64-unknown-linux-gnu) Building stage1 std artifacts (x86_64-unknown-linux-gnu -> x86_64-buildroot-linux-gnu) error: failed to run `rustc` to learn about target-specific information ... error: Error loading target specification: Could not find specification for target "x86_64-buildroot-linux-gnu". Run `rustc --print target-list` for a list of built-in targets I wonder how to define a "target specification" with a custom vendor value.
Created attachment 9571 [details] Use the toolchain's vendor string to identify the rustc target. I uploaded the patch we use to build the toolchain. I only tested it on 2023.02. This patch add the support of the triplet x86_64-buildroot-linux-gnu into the rustc source code: It means that if the TARGET_VENDOR variable is set to somethings else than "buildroot" (via the BR2_TOOLCHAIN_BUILDROOT_VENDOR option), it will not work.
Thank you for your report. The issue tracker for the Buildroot project has been moved to the Gitlab.com issue tracker: https://gitlab.com/buildroot.org/buildroot/-/issues We are taking this opportunity to close old issues in this old tracker. If you believe your issue is still relevant, please open one in the new issue tracker. Thank you!