Error running instructions in Quickstart

[protoben]

I'm trying to run the instructions from the Quickstart and I'm (newly, as of this week, I think) unable to compile a guest program. One of the errors seems to be fixed by unpinning the Rust nightly version, but doing so invokes a Rust compiler bug, as described below. If someone could help me figure out the right way to fix the issue, I'd happily make a PR.

When I run cargo +nightly-2024-09-30 install --git https://github.com/a16z/jolt --force --bins jolt, as in the quickstart guide, I get an error when trying to compile jolt:

Caused by:
  rustc 1.83.0-nightly is not supported by the following package:
    bytemuck_derive@1.9.2 requires rustc 1.84

I can fix this by using +nightly, without pinning to a version, instead. This allows me to install the jolt executable. Should the nightly version be unpinned in the quickstart guide and rust-toolchain.toml?

When I create a project and try to compile the guest with cargo run --release, I get the same error as above. I can get past this by running cargo +nightly run --release instead, but then I run into a Rust compiler bug, involving a number of errors like this one:

error: internal compiler error: Encountered anon const with inference variable args but no error reported

That appears to be this bug, but I'm not sure how to get past it in order to compile a Rust guest.

Any help would be greatly appreciated. Thanks!

For reference, here are steps to reproduce the Rust version mismatch:

$ cargo +nightly install --git https://github.com/a16z/jolt --force --bins jolt
$ jolt new foo
$ cd foo
$ cargo run --release

And here are steps to reproduce the compiler bug:

$ cargo +nightly install --git https://github.com/a16z/jolt --force --bins jolt
$ jolt new foo
$ cd foo
$ cargo +nightly run --release

[moodlezoup]

Will fix in #619
In the meantime, you can put #![feature(generic_const_exprs)] in both foo/src/main.rs and foo/guest/src/lib.rs and use cargo +nightly run --release

[protoben]

Thanks!

Unfortunately, the temporary fix you mentioned seems to result in a different error for me when compiling the foo executable:

Undefined symbols for architecture arm64:
            "__HEAP_PTR", referenced from:
                _sys_alloc in foo-1e18f30608e441b5.foo.d82af649ffaf1e1a-cgu.0.rcgu.o
          ld: symbol(s) not found for architecture arm64
          clang: error: linker command failed with exit code 1 (use -v to see invocation)

Any idea what I might be doing wrong?

[protoben]

Also, do you think it would be reasonable to put something in CI to catch SDK breakages like this? If so, I can make an issue. We might have some time we could devote to doing that, along with finishing up #616.

[moodlezoup]

Also, do you think it would be reasonable to put something in CI to catch SDK breakages like this? If so, I can make an issue. We might have some time we could devote to doing that, along with finishing up #616.

Yes, I think that's a good idea. Does #619 fix the error?

[protoben]

Thanks! It solves the original issue, but I still get the linker error I indicated here when running the quickstart instructions on an M1 Mac.

I'll go ahead and make another issue, if that's OK, since this seems like it's probably a different problem.