Repository navigation
libstd: -Z build-std is now broken for Cortex-M targets #98378
Copy link
Copy link
Closed
Labels
C-bugCategory: This is a bug.Category: This is a bug.
Description
Steps to reproduce
Expected this to work with a recent nightly but it didn't.
$ rustup default nightly-2022-06-22
$ rustup component add rust-src
$ rustup component add thumbv7m-none-eabi
$ cargo new --lib foo
$ cd foo
$ echo '#![no_std]' > src/lib.rs
$ cargo build -Z build-std --target thumbv7m-none-eabi
(..)
error: `sys_common::condvar::Condvar::new` is not yet stable as a const fn
--> /home/japaric/.rustup/toolchains/nightly-2022-06-22-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/sync/condvar.rs:129:26
|
129 | Condvar { inner: sys::Condvar::new() }
| ^^^^^^^^^^^^^^^^^^^
|
= help: const-stable functions can only call other const-stable functions
error: `sys_common::mutex::MovableMutex::new` is not yet stable as a const fn
--> /home/japaric/.rustup/toolchains/nightly-2022-06-22-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/sync/mutex.rs:220:20
|
220 | inner: sys::MovableMutex::new(),
| ^^^^^^^^^^^^^^^^^^^^^^^^
|
= help: const-stable functions can only call other const-stable functions
error: `sys_common::rwlock::MovableRwLock::new` is not yet stable as a const fn
--> /home/japaric/.rustup/toolchains/nightly-2022-06-22-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/sync/rwlock.rs:153:20
|
153 | inner: sys::MovableRwLock::new(),
| ^^^^^^^^^^^^^^^^^^^^^^^^^
|
= help: const-stable functions can only call other const-stable functions
error: could not compile `std` due to 3 previous errorsThe most recent PR that touched code related to those lines is #97791.
Retrying the above steps with an older nightly (nightly-2022-06-18) before #97791 was merged works fine.
I find a bit odd that -Z build-std re-compiles libstd for a no-std target; I presume it's recompiling it to recompile proc_macro for the host. (?)
What's more strange is that using --target=$HOST works fine with nightly-2022-06-22.
$ # same Cargo project as before
$ rustc -Vv | rg host
host: x86_64-unknown-linux-gnu
$ cargo build -Z build-std --target x86_64-unknown-linux-gnu && echo OK
Compiling std
(..)
Compiling proc_macro
(..)
OKSo I'm not sure why libstd fails to compile for the host with -Z build-std --target=thumbv7m-none-eabi but not with -Z build-std --target=$HOST
Meta
$ rustc -Vv
rustc 1.63.0-nightly (dc80ca78b 2022-06-21)
binary: rustc
commit-hash: dc80ca78b6ec2b6bba02560470347433bcd0bb3c
commit-date: 2022-06-21
host: x86_64-unknown-linux-gnu
release: 1.63.0-nightly
LLVM version: 14.0.5Workaround
Using -Z build-std=core (or =alloc) with thumbv7m-none-eabi compiles fine.
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
C-bugCategory: This is a bug.Category: This is a bug.
Activity
ChrisDenton commentedon Jun 22, 2022
I think this might be a duplicate of #98293?
japaric commentedon Jun 22, 2022
seems related. they seem to be using
x.pyto build std for the uefi target (judging from thestage1in the file path) whereas here I'm using-Z build-stdfor a cortex-m target. if the uefi target (I'm not familiar with it) is also a no-std target the root cause may be the same.Ayush1325 commentedon Jun 23, 2022
The cause in my case (UEFI) seems to be that building
restcited_stdis broken now.japaric commentedon Jun 24, 2022
submitted a fix in PR #98457 (not sure it's the right fix however)
use a smaller 'std' facade for no-std targets
wcampbell0x2a commentedon Aug 25, 2022
Any update on this? I'm seeing the same issue with
cargo +nightly build --release -Zbuild-std --target thumbv7em-none-eabiAuto merge of rust-lang#98457 - japaric:gh98378, r=m-ou-se