Closed FrackinFamous closed 9 months ago
I've just arrived here looking for a solution to this.
Running with solana-test-validator
which appears to be running fine, I get the following error using cargo build-bpf
:
Error: Function _ZN112_$LT$solana_program..instruction..InstructionError$u20$as$u20$solana_frozen_abi..abi_example..AbiEnumVisitor$GT$13visit_for_abi17h8d5db8dd5086d5f8E Stack offset of 4584 exceeded max offset of 4096 by 488 bytes, please minimize large stack variables
System info: Apple Arm (M1) solana-cli 1.18.0 stable-aarch64-apple-darwin (default) rustc 1.75.0 (82e1608df 2023-12-21)
Running cargo-build-sbf --version solana-cargo-build-sbf 1.18.0 platform-tools v1.39 rustc 1.72.0
Some insights would be appreciated. I saw a Stack offset error on another issue where they suspected it was the test validator? Possibly a red herring.
I met the same problem after upgrading to 1.18.0. After struggling for a couple of hours, I downgraded to 1.17.17 finally, and it works again without the Stack exceed max capacity
error.
# download Solana tool v1.17.17
sh -c "$(curl -sSfL https://release.solana.com/v1.17.17/install)"
# force to redownload rust toolchains
cargo-build-sbf --force-tools-install
And, all the dependencies should be at "1.17.17" as well.
[dependencies]
borsh = { version = "0.10.3" }
borsh-derive = { version = "0.10.3" }
chrono = "0.4.33"
solana-program = "=1.17.17"
spl-token = "4.0.0"
[dev-dependencies]
solana-program-test = "1.17.17"
solana-sdk = "1.17.17"
Finally, I succeeded. :smile:
❯ cargo build-sbf
Finished release [optimized] target(s) in 0.46s
@vebodev it tries to build 1.18.0 no matter what I do! Ugh so frustrating lol. Why has no one told us a way to just pin to the Soloana version of rustc or come up with a better way to do this install. Maybe write a script one time and never run into this problem every single time they do an update.
HOLY SHIT!!!!!!
Not sure what I did but.....I think it was adding in the =
inside the parenthesis solana-program = "=1.17.17"
to pin the exact version rather than the way that 98% of the instructions say to do it including the ones in solana-program on crates.io.
DEVS PLEASE FOR LOVE OF GOD UPDATE THE WEBSITE FOR THE HELLO WORLD APP! (caps are because I am screaming not because I'm ignorant) 😄 Not sure how much you value your time but simple one time description of this on the website would keep it from resurfacing over and over and save me literally 20 hours and mfing you all the whole time. Please and Thank you.
@FrackinFamous by updating the website for hello world app, do you mean https://github.com/solana-foundation/developer-content/blob/main/content/guides/getstarted/local-rust-hello-world.md ? If you have some particular things you think will be helpful for the newcomers, could you create a PR for this md file?
@KirillLykov I will surely try the install from scratch again tomorrow and make a PR once I figure out exactly what I did. Haha. Very tired now. Yes I am in fact talking about that article. I'm not really sure what I did would be a relevant way to fix it though because I still don't know how to install the latest version. Like I said that simple extra =
apparently saved the day. Maybe making the site give exact numbers of known versions that work together and then updating that every so often.
I guess technically the problem lies in this article and the documentation:
https://solana.com/developers/guides/getstarted/setup-local-development
Neither of which say anything about having to pinning the solana-program crate to match the cli version you installed which is what @billythedummy was trying to tell me the whole time but I ended up finally getting it through my head after watching @vebodev do it lol.
So yes the article and the docs need to have an aside about making the the solana-cli == solana-program crate.
HOLY SHIT!!!!!!
Not sure what I did but.....I think it was adding in the
=
inside the parenthesissolana-program = "=1.17.17"
to pin the exact version rather than the way that 98% of the instructions say to do it including the ones in solana-program on crates.io.DEVS PLEASE FOR LOVE OF GOD UPDATE THE WEBSITE FOR THE HELLO WORLD APP! (caps are because I am screaming not because I'm ignorant) 😄 Not sure how much you value your time but simple one time description of this on the website would keep it from resurfacing over and over and save me literally 20 hours and mfing you all the whole time. Please and Thank you.
Congratulation! Rust world does have a lot of wired stuffs.
I met the same problem after upgrading to 1.18.0. After struggling for a couple of hours, I downgraded to 1.17.17 finally, and it works again without the
Stack exceed max capacity
error.
@vebodev Thank you! After following your steps, I can confirm this works for me on 1.17.17
as well. After doing the initial cargo-build-sbf --force-tools-install
I can now use cargo-build-sbf
in the normal manner for a successful build 🙏
More on this if you ever run into such dependencies issues in the future:
Cargo.toml
actually defaults to ^version
in semver terms if there is no qualifier. So solana-program = "1.17"
means ^1.17.0
means >=1.17.0,<2.0.0
. For packages below version 1.0
, this has a different meaning: borsh = "0.8"
means ^0.8
means >=0.8.0,<0.9.0
. Details: https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#specifying-dependencies-from-cratesio1.X.Y
to 1.A.B
, or 0.11.X
to 0.11.A
should not break your build. However, the solana libraries do not follow this and may break across minor versions - so 1.18.X
might not be compatible with 1.16.X
. So keep this in mind when upgrading your programs. More details hereCargo.lock
file and searching for the entry for that package:
solana-*
dependencies to that version in Cargo.toml
, so solana-program = "=1.18.0"
Cargo.lock
file, download dependencies, and cargo check
everything to make sure everything compiles fine, or perform a cargo check
manually to do so.Cargo.toml
to be unpinned, solana-program = "^1"
, so that others can you use your program as a library without any dependency issues. This step should not modify the Cargo.lock
file.Cargo.lock
file to get your stuff to build correctly because a dependency is using the wrong version of a sub-dependency. The most common source of this problem for me is the borsh
dependency because the various solana libraries have 3 different versions of borsh: 0.9.3, 0.10.3, and 0.7.2, which are all incompatible with each other in rust semver terms. When that happens you can change the version of the sub-dependency in your Cargo.lock
. For example:
This should only be done as a last resort, and most of the time it wont work because that dependency itself probably has constrained the sub-dependency's version to a semver compatible range. The example above wont work if the dependency's Cargo.toml
specifies borsh = "^0.10"
, but it'll work if it's something like borsh = ">=0.9,<1.0.0"
@billythedummy That was a wealth of info and thank you for sticking with me. Sometimes (me always) we can't understand the solution without getting in there an going through it a bit. This was fantastic info albeit a bit scary... I understand Solana are growing fast but I could see this mix matching getting out of hand without a way to tie everything together. It's like a grown up version of my own project folders when I forget version control exists. 🤣
Thanks for pointing this out. Definitely want to make sure the first experience working with Solana is seamless.
I've added something I think may help, based on this thread. https://github.com/solana-foundation/developer-content/pull/53
In the future, feel free to also PR changes into the documentation, to help the next person!
Thanks for pointing this out. Definitely want to make sure the first experience working with Solana is seamless.
I've added something I think may help, based on this thread. solana-foundation/developer-content#53
In the future, feel free to also PR changes into the documentation, to help the next person!
Sure thing! Thanks for the addition and I apologize for the frustration. Obviously I am a bit sarcastic so nothing meant by it. I appreciate the communities quick help and feedback. I'll be sure to help out with anything I learn.
Problem
This is broken: https://solana.com/developers/guides/getstarted/local-rust-hello-world
If you start with a fresh linux system and run this tutorial you will fail.
Proposed Solution
A team member recording a video going through this step by step and proving it works.
Hello Guys, I need little favour. https://solana.com/developers/guides/getstarted/local-rust-hello-world I am following this steps exactly but after build process gets completed I am unable to find ./target/deploy directory. I am getting ./target/release, ./target/sbf-solana-solana,./target/.rustc_info.json and ./target/CACHEDIR.TAG
I am unable to locate my binary .so files and that's why unable to deploy program. Thanks In Advance
This is My Cargo.toml [package] name = "hello_world" crate-type = ["cdylib", "lib"] version = "0.1.0" edition = "2021"
[dependencies] solana-program = "1.18.0"
@YatharthAndharia normally cargo build-sbf
should have created this so file. Btw, using build-bpf
like in the documentation is equivalent but deprecated way
@YatharthAndharia We can't keep answering development/debugging questions here, but you haven't set up the Cargo.toml
the way that the tutorial you've linked has instructed you to do.
This is My Cargo.toml
[package] name = "hello_world" crate-type = ["cdylib", "lib"] version = "0.1.0" edition = "2021"
The tutorial says to do this:
[package] name = "hello_world" version = "0.1.0" edition = "2021" [lib] name = "hello_world" crate-type = ["cdylib", "lib"]
[lib][crate-type][cdylib]
is what instructs cargo build-sbf
to write to a shared object .so
file.
Guys I'm going to close this since this isn't a bug, it's some dependency mismatch annoyance - which I know is not fun.
If there's further issues I encourage the Stack Exchange, and if you find something with 1.18
that's truly a bug or flaw, then we can discuss in a new issue!
@YatharthAndharia We can't keep answering development/debugging questions here, but you haven't set up the
Cargo.toml
the way that the tutorial you've linked has instructed you to do.This is My Cargo.toml
[package] name = "hello_world" crate-type = ["cdylib", "lib"] version = "0.1.0" edition = "2021"
The tutorial says to do this:
[package] name = "hello_world" version = "0.1.0" edition = "2021" [lib] name = "hello_world" crate-type = ["cdylib", "lib"]
[lib][crate-type][cdylib]
is what instructscargo build-sbf
to write to a shared object.so
file.
oh my gosh, ive been bashing my head all night ! and you were right. Well... I learned a lot regardless. I learned to match my solana cli to a compatible version of what package i use cargo add solana-program@"=1.17.17"
(in my case) and a bunch of other stuff... but my problem was somehow more todo with Cargo.toml
not matching exactly. I had the crate-type var in the [package] section and didnt have a [lib] section.
Coming from node / python i was like man i miss complied languages. haven't touched rust in a minute. I guess i gotta get used to this!
Thanks everyone here and all the other places I looked, i finally got my /target/deploy/hello_world.so
file actually being output, which was my problem about halfway through.
Cheers!
I had a similar issue which was not fixed with =1.17.17
but thanks to joncinque - it is fixed in 1.18.2 and I managed to have it working.
It would be great if anyone sees this would fix the documentation: https://solana.com/developers/guides/getstarted/local-rust-hello-world and the code sample: https://github.com/solana-labs/example-helloworld/tree/master/src/program-rust
Source: https://github.com/solana-labs/solana/issues/35003#issuecomment-1970028870
Problem
This is broken: https://solana.com/developers/guides/getstarted/local-rust-hello-world
If you start with a fresh linux system and run this tutorial you will fail.
Proposed Solution
A team member recording a video going through this step by step and proving it works.