-
Notifications
You must be signed in to change notification settings - Fork 174
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
Build fail on MacOS: feature(asm) may not be used on the stable release channel #301
Comments
I recall @ahl running into something similar not too long ago. |
In the meantime, perhaps try |
@dancrossnyc that feels like it got further but we have a different failure:
|
Hmm, that feels like a different issue: |
A few notes:
* .cargo/confg in the hubris repo aliases xtask to `run --package xtask --`
which runs the program in HUBRIS_ROOT/build/xtask/src/main.rs
* xtask runs `cargo rustc` internally (see build() in build/xtask/src/
dist.rs)
* Hubris uses a rust-toolchain.toml to specify the channel and targets
This all points to `cargo rustc` invoked by `cargo xtask` not using the
rust-toolchain.toml. I think @ahl had a situation where there were
multiple Rust installs and `cargo` on the command-line ran a different
cargo from the invocation done by `cargo xtask`. Also check that you have
a new enough rustup that supports the rust-toolchain.toml that specifies
targets.
…On Mon, Dec 6, 2021 at 1:14 PM Georg Nikodym ***@***.***> wrote:
@dancrossnyc <https://github.com/dancrossnyc> that feels like it got
further but we have a different failure:
➜ hubris git:(master) cargo +nightly xtask dist app/demo-stm32h7-nucleo/app-h7b3.toml
Compiling libc v0.2.105
Compiling proc-macro2 v1.0.32
Compiling unicode-xid v0.2.2
[...elided...]
Compiling num-derive v0.3.3
Compiling zerocopy v0.3.0
Compiling ssmarshal v1.0.0
Compiling abi v0.1.0 (/Users/georgn/git/hubris/sys/abi)
error[E0658]: const operands for inline assembly are unstable
--> sys/userlib/src/lib.rs:152:9
|
152 | sysnum = const Sysnum::Send as u32,
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= note: see issue #72016 <rust-lang/rust#72016> for more information
= help: add `#![feature(asm_const)]` to the crate attributes to enable
error[E0658]: const operands for inline assembly are unstable
--> sys/userlib/src/lib.rs:302:9
|
302 | sysnum = const Sysnum::Recv as u32,
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= note: see issue #72016 <rust-lang/rust#72016> for more information
= help: add `#![feature(asm_const)]` to the crate attributes to enable
error[E0658]: const operands for inline assembly are unstable
--> sys/userlib/src/lib.rs:361:9
|
361 | sysnum = const Sysnum::Reply as u32,
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= note: see issue #72016 <rust-lang/rust#72016> for more information
= help: add `#![feature(asm_const)]` to the crate attributes to enable
error[E0658]: const operands for inline assembly are unstable
--> sys/userlib/src/lib.rs:424:9
|
424 | sysnum = const Sysnum::SetTimer as u32,
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= note: see issue #72016 <rust-lang/rust#72016> for more information
= help: add `#![feature(asm_const)]` to the crate attributes to enable
error[E0658]: const operands for inline assembly are unstable
--> sys/userlib/src/lib.rs:473:9
|
473 | sysnum = const Sysnum::BorrowRead as u32,
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= note: see issue #72016 <rust-lang/rust#72016> for more information
= help: add `#![feature(asm_const)]` to the crate attributes to enable
error[E0658]: const operands for inline assembly are unstable
--> sys/userlib/src/lib.rs:533:9
|
533 | sysnum = const Sysnum::BorrowWrite as u32,
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= note: see issue #72016 <rust-lang/rust#72016> for more information
= help: add `#![feature(asm_const)]` to the crate attributes to enable
error[E0658]: const operands for inline assembly are unstable
--> sys/userlib/src/lib.rs:599:9
|
599 | sysnum = const Sysnum::BorrowInfo as u32,
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= note: see issue #72016 <rust-lang/rust#72016> for more information
= help: add `#![feature(asm_const)]` to the crate attributes to enable
error[E0658]: const operands for inline assembly are unstable
--> sys/userlib/src/lib.rs:636:9
|
636 | sysnum = const Sysnum::IrqControl as u32,
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= note: see issue #72016 <rust-lang/rust#72016> for more information
= help: add `#![feature(asm_const)]` to the crate attributes to enable
error[E0658]: const operands for inline assembly are unstable
--> sys/userlib/src/lib.rs:669:9
|
669 | sysnum = const Sysnum::Panic as u32,
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= note: see issue #72016 <rust-lang/rust#72016> for more information
= help: add `#![feature(asm_const)]` to the crate attributes to enable
error[E0658]: const operands for inline assembly are unstable
--> sys/userlib/src/lib.rs:749:9
|
749 | sysnum = const Sysnum::GetTimer as u32,
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= note: see issue #72016 <rust-lang/rust#72016> for more information
= help: add `#![feature(asm_const)]` to the crate attributes to enable
error[E0658]: sym operands for inline assembly are unstable
--> sys/userlib/src/lib.rs:820:9
|
820 | main = sym main,
| ^^^^^^^^^^^^^^^
|
= note: see issue #72016 <rust-lang/rust#72016> for more information
= help: add `#![feature(asm_sym)]` to the crate attributes to enable
error[E0658]: const operands for inline assembly are unstable
--> sys/userlib/src/lib.rs:894:9
|
894 | sysnum = const Sysnum::RefreshTaskId as u32,
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= note: see issue #72016 <rust-lang/rust#72016> for more information
= help: add `#![feature(asm_const)]` to the crate attributes to enable
error[E0658]: const operands for inline assembly are unstable
--> sys/userlib/src/lib.rs:930:9
|
930 | sysnum = const Sysnum::Post as u32,
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= note: see issue #72016 <rust-lang/rust#72016> for more information
= help: add `#![feature(asm_const)]` to the crate attributes to enable
For more information about this error, try `rustc --explain E0658`.
error: could not compile `userlib` due to 13 previous errors
Error: failed to build jefe
Caused by:
command failed, see output for details
➜ hubris git:(master)
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#301 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACIEHF7GMQ3GAD7GIXZUPCTUPURT7ANCNFSM5JPHKPHQ>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
|
@dancrossnyc your suggestion of naming a specific nightly works (at least, I build to completion)... next step, connect my and flash my board. Thanks! |
Sure thing, though you should definitely follow the debugging steps Rick outlined; what you're seeing is not the expected behavior. |
@MMI I hit a similar looking (although possibly unrelated) issue that I found to be related to a very very old rustup install (possibly from homebrew). I think it was from 2015 or 2016. I resolved it by ripping out anything related to rustup and cargo root and branch and then reinstalling. |
Unfortunately, I'm a bit of a rust-curious n00b (to borrow Bryan's metaphor)... so Rick's debugging "steps" are somewhat opaque to me just now... Of course, suspecting a rust version problem was precisely why I included the Doing |
Nothing wrong with that! :-)
Something I've observed in the past is that
Personally, I stick with |
I'd strongly discourage using It sounds like your toolchain is ignoring our
|
Thanks for everybody's help. With some free time over the holidays I revisited... Turns out that So now the only path to rust things is via
If I try to explicitly set my default:
It certainly looks like your However, this setting breaks the build in other ways (I'll spare you the output but the errors come from That suggests that there is some part(s) of your build that is not noticing the For me, it seems that the only path through the labyrinth appears to be |
We've seen this behavior on Macs a few times and, not having a Mac, I am not sure how it happens. Closing this for now. |
No argument here... it's in the google record now for the next victim 😄 |
This is probably a local config problem but...
Any hints or suggestions welcome.
The text was updated successfully, but these errors were encountered: