pd-rs
Hardware Build Fails with Playdate SDK 1.13.1
Build fails on hardware with Playdate SDK 1.13.1. The build worked last time I checked with 1.12.X. My device did not get the 1.13.0 update.
$ cat $PLAYDATE_SDK_PATH/VERSION.txt
1.13.1
$ rustc -V
rustc 1.69.0-nightly (13471d3b2 2023-03-02)
$ crank run --release --example=hello_world --device
warning: dropping unsupported crate type `cdylib` for target `thumbv7em-none-eabihf`
warning: `crankstart` (example "hello_world") generated 1 warning
Finished release [optimized] target(s) in 0.09s
/usr/local/playdate/gcc-arm-none-eabi-9-2019-q4-major/bin/../lib/gcc/arm-none-eabi/9.2.1/../../../../arm-none-eabi/bin/ld: /Users/bsechter/projects/playdate/crankstart/target/thumbv7em-none-eabihf/release/examples/libhello_world.a(compiler_builtins-8d574003699b34d6.compiler_builtins.58342f1c-cgu.4.rcgu.o): in function `OUTLINED_FUNCTION_15':
compiler_builtins.58342f1c-cgu.4:(.text.OUTLINED_FUNCTION_15+0x6): undefined reference to `<T as core::convert::TryInto<U>>::try_into'
collect2: error: ld returned 1 exit status
Error: gcc failed with error ExitStatus(unix_wait_status(256))
$
All examples and the Klondike solitaire application fail with the above error. They all run fine in the simulator.
For whatever reason, I'm stuck at rustc 1.68.0-nightly (b70baa4f9 2022-12-14) on the Mac. Does this occur with that version of the Rust toolchain?
Short answer, yes.
$ rustup install nightly-2022-12-14
nightly-2022-12-14-x86_64-apple-darwin installed - rustc 1.68.0-nightly (0f529f0f4 2022-12-13)
$ rustup default nightly-2022-12-14
$ rustc -V
rustc 1.68.0-nightly (0f529f0f4 2022-12-13)
$ cargo clean
$ crank run --release --example=hello_world --device
The above list of commands results in the same error. Note that my exact version of 1.68.0-nightly is slightly different from the one you are stuck at.
$ ex -s +'%s/<[^>].\{-}>//ge' +'%s/\s\+//e' +'%norm J' +'g/^$/d' +%p +q! /System/Library/CoreServices/SystemVersion.plist | grep -E 'ProductName|ProductVersion' | sed 's/^[^ ]* //g' | sed 'N; s/\n/ /g'
macOS 11.7.4
$ uname -vm
Darwin Kernel Version 20.6.0: Fri Dec 16 00:35:00 PST 2022; root:xnu-7195.141.49~1/RELEASE_X86_64 x86_64
$ sysctl -n machdep.cpu.brand_string
Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz
Does crank build --release --example=hello_world --device work locally for you with Playdate SDK 1.13.1?
It works on my newer MacBook, but fails on the older iMac. MacBook details below. Not sure what the problem is, but it is not SDK 1.13.1.
$ ex -s +'%s/<[^>].\{-}>//ge' +'%s/\s\+//e' +'%norm J' +'g/^$/d' +%p +q! /System/Library/CoreServices/SystemVersion.plist | grep -E 'ProductName|ProductVersion' | sed 's/^[^ ]* //g' | sed 'N; s/\n/ /g'
macOS 12.6
$ uname -vm
Darwin Kernel Version 21.6.0: Mon Aug 22 20:19:52 PDT 2022; root:xnu-8020.140.49~2/RELEASE_ARM64_T6000 arm64
$ sysctl -n machdep.cpu.brand_string
Apple M1 Max
$ cat $PLAYDATE_SDK_PATH/VERSION.txt
1.13.1
$ rustc -V
rustc 1.67.0-nightly (c97b539e4 2022-11-30)
No contest. Without doing any deep digging, <T as core::convert::TryInto<U>>::try_into appears to be implicitly called, but the function is not making it into the binary. Reverting to older versions of Rust on the desktop does not seem to solve the problem though, so I do not know what is going on.
I am starting to think it is a Rust bug in that most recent nightly.
A couple of questions.
- Does crankstart still need to rely on nightly? Is stable missing something necessary?
- Does
crank run --release --example hello_world --deviceactually upload the PDX to hardware and start running it on your development machine? I have not been able to get it to work.
Crankstart uses a custom allocator, which is nightly-only.
https://doc.rust-lang.org/std/alloc/trait.Allocator.html
Running on device worked last week, when I updated to SDK 1.13. I've not plugged it in again since.
There's stabled custom allocator error handler. I'm not sure that is it but I'll look in in couple of days on latest macOS M1.
Getting the same error here if I can be of any help testing things.
M1 Max, Playdate SDK 1.13.1, MacOS 13.2.1, rustc 1.70.0-nightly (8a73f50d8 2023-03-11)
First go with crankstart, so I can't say when it stopped working.
FWIW, someone I asked thought that it might have to do with the -Z build-std flags. So far as I can tell, these flags are passed in by crank, and they affect the compiler builtins. I have not tried to modify crank.
It was necessary when I first wrote crank and crankstart, but perhaps it no longer is. It's worth trying to remove it and see what happens.
Removing -Z build-std from crank does work! You will get errors without adding the thumbv7em-none-eabihf target though rustup target add thumbv7em-none-eabihf.
This seems to be a semi-recent regression in nightly (I use stable 1.67.1 with crank/crankstart and do not experience this issue). See https://github.com/rust-lang/rust/issues/108392 and https://github.com/rust-lang/rust/issues/108853
Judging by the latter, it looks like turning off LTO on the build would get it to work correctly until it is fixed
Opened up a PR (pd-rs/crank#37) to remove -z build-std if that route is ok, can close if we would rather keep it and have it fixed via Rust nightly at some point.
I use stable 1.67.1 with crank/crankstart
If stable works, using stable instead of nightly strikes me as the best solution. (On the macOS 11.7.4 x86_64, stable 1.68.0 (2c8cc3432 2023-03-06) is not working for me. Same error.)
Opened up a PR (pd-rs/crank#37) to remove
-z build-stdif that route is ok, can close if we would rather keep it and have it fixed via Rust nightly at some point.
Since this may go back and forth, maybe it makes sense to add a flag to crank, and then add a note about the flag?
Stable should not work, for the reason I mention about about the need for a custom allocator.
When building for device, Crank specifies nightly on the cargo command line..
I'd rather not have a switch here. If -z build-std is no longer needed, lets just remove it.
Stable should not work, for the reason I mention about about the need for a custom allocator.
Ah, I actually forgot that I, uh, may have been setting RUSTC_BOOTSTRAP=1 in my environment which lets you use nightly features on a stable release version...
I'd rather not have a switch here. If -z build-std is no longer needed, lets just remove it.
I'll try to make a PR to let people specify extra Cargo flags in general instead, which would allow adding -Z build-std if some people need it
New version of crank confirmed to be working on my machine. When using stable, compiling for hardware worked, but compiling for the simulator failed. Using an earlier version of rust failed when using the prior version of crank, so I suspect that the hardware build strategy is doing something with a false assumption baked in. I have not looked at the code to diagnose anything.
$ rustup default stable
$ cargo clean
$ crank build --release --device
*snip*
Finished release [optimized] target(s) in 19.82s
$ crank build --release
*snip*
error[E0554]: `#![feature]` may not be used on the stable release channel
--> ~/.cargo/registry/src/github.com-1ecc6299db9ec823/cstr_core-0.1.2/src/lib.rs:12:40
|
12 | #![cfg_attr(feature = "alloc", feature(alloc))]
| ^^^^^
For more information about this error, try `rustc --explain E0554`.
error: could not compile `cstr_core` due to previous error
warning: build failed, waiting for other jobs to finish...
Error: cargo failed with error ExitStatus(unix_wait_status(25856))
$ rustup default nightly
$ cargo clean
$ crank build --release --device
*snip*
Finished release [optimized] target(s) in 19.82s
$ crank build --release
*snip*
Finished release [optimized] target(s) in 12.80s
@sgeos, crank internally requests nightly for the rustup cargo bin (via +nightly) but only when building for the device
So when it succeeds to actually build for the device, it's still using nightly instead of the default toolchain (try uninstalling the nightly toolchain instead of just changing the default to confirm this)