You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Apr 11, 2022. It is now read-only.
Hi,
I've recently been experimenting building the code using cargo instead of xargo for an ESP32, so I can use it as a basis for my own projects.
Since xargo is in maintenance mode and cargo-xbuild now recommends using vanilla cargo with the build-std feature
Thanks for all you're hard work btw on getting rust running on the esp32
What I've discovered is that this seems to work in release but not in debug mode
I think it's because the mem functions from esp32hal are conflicting with with the ones in compiler-builtins
Changes for Cargo build
First these are the changes I made to build using cargo instead of xargo
First rename .config/config to .config/config.toml
This isn't actually needed but seems to be the new convention
although the old xargo doesn't pick up on .config/config.toml only cargo does that
Next switch to the nightly toolchain, I think this gives the latest version of cargo
even though I'm using a custom rustc / llvm build for the esp32
rustup default nightly
Next instead of setting environmental variables like with xargo
we can now add the custom paths to rustc / rustdoc in the .config/config.toml
# Set Backtrace
set export RUST_BACKTRACE=1
# To build debug - This fails
cargo build --example esp32
# To build release - This works
cargo build --example esp32 --release
Whereby the mem functions are being picked up by both esp32hal and compiler-builtins at the same time
c:/apps/xtensa-esp32-elf/bin/../lib/gcc/xtensa-esp32-elf/8.4.0/../../../../xtensa-esp32-elf/bin/ld.exe: D:\SourceCode\External\xtensa-rust-quickstart\target\xtensa-esp32-none-elf\debug\deps\libcompiler_builtins-c4239eb2059dfa6f.rlib(compiler_builtins-c4239eb2059dfa6f.compiler_builtins.98f1mwpt-cgu.7.rcgu.o): in function `memset':
C:\Users\ric\.cargo\registry\src\github.com-1ecc6299db9ec823\compiler_builtins-0.1.35\src/mem.rs:43: multiple definition of `memset'; D:\SourceCode\External\xtensa-rust-quickstart\target\xtensa-esp32-none-elf\debug\deps\libesp32_hal-1917a2d435a3be16.rlib(esp32_hal-1917a2d435a3be16.esp32_hal.7rewnego-cgu.2.rcgu.o):C:\Users\ric\.cargo\registry\src\github.com-1ecc6299db9ec823\esp32-hal-0.2.0\src/mem.rs:205: first defined here
collect2.exe: error: ld returned 1 exit status
I have a feeling that it's related to the mem feature within compiler-builtins
although it's odd that it passes through release.
I'm guessing that xargo / cargo-xbuild are forcing that feature to be off which isn't a standard thing you can do under cargo since features are accumulative
I also noticed the final binary was 100Kb larger in release mode when built with cargo vs xargo (in that the cargo built version was bigger)
although that might be the mem feature being enabled perhaps or the fact
it's pulling in the core / rustc-std-workspace-core libraries
Any thoughts?
I can build with xargo, it just seems that cargo is more convenient since it needs less env variables to be set
I've not been using rust that long (past week or so) so I'm currently looking into if there's a way I can fudge the mem feature to off in some way
possibly disabling all default features is something I've not tried yet
Now that rust-lang/compiler-builtins#411 is merged, we are step closer to building with just cargo 🎉 . Will need a compiler builtins release, then I will need to update the rust-xtensa fork, which I want to do anyways as we now have const generics on stable.
I also noticed the final binary was 100Kb larger in release mode when built with cargo vs xargo (in that the cargo built version was bigger)
Hmm thats odd. Are you noticing that in size of the elf file, or is that the increased size once you've converted from elf to bin? If its in the elf, it may be debug symbols from the core lib perhaps.
Hi,
I've recently been experimenting building the code using cargo instead of xargo for an ESP32, so I can use it as a basis for my own projects.
Since xargo is in maintenance mode and cargo-xbuild now recommends using vanilla cargo with the build-std feature
Thanks for all you're hard work btw on getting rust running on the esp32
What I've discovered is that this seems to work in release but not in debug mode
I think it's because the mem functions from esp32hal are conflicting with with the ones in compiler-builtins
Changes for Cargo build
First these are the changes I made to build using cargo instead of xargo
First rename .config/config to .config/config.toml
This isn't actually needed but seems to be the new convention
although the old xargo doesn't pick up on .config/config.toml only cargo does that
Next switch to the nightly toolchain, I think this gives the latest version of cargo
even though I'm using a custom rustc / llvm build for the esp32
we can now add the custom paths to rustc / rustdoc in the .config/config.toml
Next I added to Config.Toml the default features to enable
just so I didn't have to keep adding them to the command line, this is just for the esp32
Finally to build
Build Failure
I get the feeling this may now have been fixed
compiler_builtins
seems to be missing symbols rust-lang/wg-cargo-std-aware#53But I think I might be running into this problem
Whereby the mem functions are being picked up by both esp32hal and compiler-builtins at the same time
I have a feeling that it's related to the mem feature within compiler-builtins
although it's odd that it passes through release.
I'm guessing that xargo / cargo-xbuild are forcing that feature to be off which isn't a standard thing you can do under cargo since features are accumulative
I also noticed the final binary was 100Kb larger in release mode when built with cargo vs xargo (in that the cargo built version was bigger)
although that might be the mem feature being enabled perhaps or the fact
it's pulling in the core / rustc-std-workspace-core libraries
Any thoughts?
I can build with xargo, it just seems that cargo is more convenient since it needs less env variables to be set
I've not been using rust that long (past week or so) so I'm currently looking into if there's a way I can fudge the mem feature to off in some way
possibly disabling all default features is something I've not tried yet
The text was updated successfully, but these errors were encountered: