Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

libstd: -Z build-std is now broken for Cortex-M targets #98378

Closed
japaric opened this issue Jun 22, 2022 · 5 comments · Fixed by #98457
Closed

libstd: -Z build-std is now broken for Cortex-M targets #98378

japaric opened this issue Jun 22, 2022 · 5 comments · Fixed by #98457
Labels
C-bug Category: This is a bug.

Comments

@japaric
Copy link
Member

japaric commented Jun 22, 2022

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 errors

The 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
(..)
OK

So 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.5

Workaround

Using -Z build-std=core (or =alloc) with thumbv7m-none-eabi compiles fine.

@japaric japaric added the C-bug Category: This is a bug. label Jun 22, 2022
@ChrisDenton
Copy link
Member

I think this might be a duplicate of #98293?

@japaric
Copy link
Member Author

japaric commented Jun 22, 2022

seems related. they seem to be using x.py to build std for the uefi target (judging from the stage1 in the file path) whereas here I'm using -Z build-std for 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
Copy link
Contributor

The cause in my case (UEFI) seems to be that building restcited_std is broken now.

@japaric
Copy link
Member Author

japaric commented Jun 24, 2022

submitted a fix in PR #98457 (not sure it's the right fix however)

japaric added a commit to japaric/cargo-call-stack that referenced this issue Jun 28, 2022
fixes #55

`-Z build-std` builds a "no op" std for the target, even no-std ones
that won't work for ARMv6-M because std depends on CAS and that target
lacks CAS
ARMv7-M also has problems with recent nightlies due to
rust-lang/rust#98378

this commit changes the logic to use a smaller `-Z build-std=alloc`
subset for no-std targets
targets are considered 'no-std' when `rustc --print=cfg --target $T`
reports `target_os="none"`
@wcampbell0x2a
Copy link
Contributor

Any update on this? I'm seeing the same issue with cargo +nightly build --release -Zbuild-std --target thumbv7em-none-eabi

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-bug Category: This is a bug.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants