compiler_builtins string.h functions are not available when using std targets with #![no_std]
#137833
Comments
byeongkeunahn
added
C-bug
rustbot
added
I-prioritize
|
Thanks for bisecting already. I don't think the compiler changes in #135501 should have affected Cargo features at all since that only affects when the already-built compiler-builtins crate gets injected; however, I am wondering whether the changes from public to private in Cargo.toml may have changed the way features get are getting enabled. Cc @rust-lang/cargo in case anybody knows of some behavior differences here. Are you able to build rustc? That theory can probably be tested by reverting 8c1b49d (Use
|
Why is this relevant? Maybe you know something about basm that I don't know, but AFAIK the problem is this: I was previously advised by t-libs that adding a Cargo dependency on the published compiler-builtins is not a use of the library that is supported, and indeed I ran into many strange linkage and crate resolution issues when I was trying to do that. |
I'm not familiar with building rustc, I'll give it a try when I have time. Thanks for the suggestion :)
I appreciate that this is not an intended use case. However, in that case, the issue is that the linking error persists when the compiler-builtins dependency is removed from Cargo.toml. If I recall correctly, the compiler-builtins dependency was added a few years ago to resolve the same linker error regarding undefined external symbols (memcpy/memset/strlen). |
|
I know nothing about basm but the original post says:
I assumed this meant they were still seeing a regression across the versions even if they removed the (But yeah, we need to do something about compiler-builtins on crates.io once we understand whether there are any remaining legitimate usecases, syncs have me very pretty of that not being a submodule/tree anyway. On my eventual todo list...) |
It's reasonably easy, If you can reproduce this with a smaller crate, I'll also try to take a closer look over the weekend. |
I've constructed a minimized version which runs on x64 Windows only. It is set to use nightly-2025-02-23. Any of the following changes will make
Furthermore, while the minimized version does not have issues with Please find the minimal example below. It is possible that I might be using the |
|
Does it work if you keep the compiler-builtins dependency with the mem feature enabled but add |
|
Oh yes, that seems to work on nightly-2025-02-24 and afterwards. More precisely, the following works: However, when the order is reversed, linking error persists: I've observed the same tendency in both the minimal example and the original repo. Unfortunately, |
Noratrieb
added
A-linkage
I'm guessing the difference is that with the first version and before #135501, the crates.io version built with rust/compiler/rustc_metadata/src/creader.rs Lines 1124 to 1131 in 8c39296 RUSTC_LOG=rustc_metadata::creader=info and comparing the output between the two.
Removing Why are you passing |
It was to reduce the binary size whenever possible. Nevertheless, the linker error pattern doesn't change even if /NODEFAULTLIB is removed. |
|
Reduced: #![no_main]
#![no_std]
extern crate alloc;
struct Allocator;
unsafe impl core::alloc::GlobalAlloc for Allocator {
unsafe fn alloc(&self, _: core::alloc::Layout) -> *mut u8 {
unimplemented!()
}
unsafe fn alloc_zeroed(&self, _: core::alloc::Layout) -> *mut u8 {
unimplemented!()
}
unsafe fn dealloc(&self, _: *mut u8, _: core::alloc::Layout) {}
unsafe fn realloc(&self, _: *mut u8, _: core::alloc::Layout, _: usize) -> *mut u8 {
unimplemented!()
}
}
#[global_allocator]
static ALLOC: Allocator = Allocator;
#[unsafe(no_mangle)]
extern "win64" fn __CxxFrameHandler3() -> ! {
unimplemented!()
}
#[panic_handler]
fn panic(_pi: &core::panic::PanicInfo) -> ! {
unimplemented!()
}
#[unsafe(no_mangle)]
pub unsafe extern "win64" fn _basm_start() -> ! {
unimplemented!()
}With Run with I am hesitant to do that though because the current behavior is generally preferable; we want to discourage direct use of I'm not sure what a better solution is, however. Maybe it's easiest to enable Cc @ChrisDenton, do you have any ideas? |
|
Thank you for the detailed analysis. One thing I'd like to note is that the linker error also occurs on Linux, not just Windows. The error message on Linux can be found at the beginning of this issue thread. The reason I limited the above example to Windows was simply to minimize the amount of code. |
|
Ah, I thought we were providing the symbols on Unix because weak linkage works well, but I guess bootstrap only sets this for no_std targets . |
tgross35
changed the title
compiler_builtins string.h functions are not available when using std targets with #![no_std]
apiraino
added
the
E-needs-investigation
Code
The basm-rs project which uses no-std with mem feature for compiler-builtins fails to build on recent nightly. It can be reproduced on nightly-2025-02-28 on Windows x64 and Linux x64 by the following:
git clone https://github.com/boj-rs/basm-rs.git cd basm-rs git reset --hard 2e3799d cargo runThe following PR seems relevant: #135501 (Inject compiler_builtins during postprocessing and ensure it is made private)
Although not sure, I suspect this might be due to the internal changes by the above PR making the mem feature ignored on the compiler-builtins crate.
Adding/removing compiler-builtins with mem feature enabled (on Cargo.toml) doesn't alleviate the issue.
I expected to see this happen: build should succeed
Instead, this happened: build fails with linker error (unresolved external symbols, LNK2001 and LNK2019 on memcpy, memset, strlen, etc.)
Linker error on Windows x64
Linker error on Linux x64
Version it worked on
It most recently worked on: nightly-2025-02-23
Version with regression
rustc --version --verbose:Output of cargo-bisect-rustc
searched nightlies: from nightly-2025-02-20 to nightly-2025-02-28
regressed nightly: nightly-2025-02-24
searched commit range: 46420c9...f8a913b
regressed commit: bca5f37
bisected with cargo-bisect-rustc v0.6.7
Host triple: x86_64-pc-windows-msvc
Reproduce with:
The text was updated successfully, but these errors were encountered: