Giter Site home page Giter Site logo

rust-build's Introduction

rust-build

This repository contains:

If you want to know more about the Rust ecosystem on ESP targets, see The Rust on ESP Book chapter

Table of Contents

Xtensa Installation

Deployment is done using espup

espup installation

cargo install espup
espup install # To install Espressif Rust ecosystem
# [Unix]: Source the following file in every terminal before building a project
. $HOME/export-esp.sh

Or, downloading the pre-compiled release binaries:

  • Linux aarch64
    curl -L https://github.com/esp-rs/espup/releases/latest/download/espup-aarch64-unknown-linux-gnu -o espup
    chmod a+x espup
    ./espup install
    # Source the following file in every terminal before building a project
    . $HOME/export-esp.sh
  • Linux x86_64
    curl -L https://github.com/esp-rs/espup/releases/latest/download/espup-x86_64-unknown-linux-gnu -o espup
    chmod a+x espup
    ./espup install
    # Source the following file in every terminal before building a project
    . $HOME/export-esp.sh
  • macOS aarch64
    curl -L https://github.com/esp-rs/espup/releases/latest/download/espup-aarch64-apple-darwin -o espup
    chmod a+x espup
    ./espup install
    # Source the following file in every terminal before building a project
    . $HOME/export-esp.sh
  • macOS x86_64
    curl -L https://github.com/esp-rs/espup/releases/latest/download/espup-x86_64-apple-darwin -o espup
    chmod a+x espup
    ./espup install
    # Source the following file in every terminal before building a project
    . $HOME/export-esp.sh
  • Windows MSVC
    Invoke-WebRequest 'https://github.com/esp-rs/espup/releases/latest/download/espup-x86_64-pc-windows-msvc.exe' -OutFile .\espup.exe
    .\espup.exe install
  • Windows GNU
    Invoke-WebRequest 'https://github.com/esp-rs/espup/releases/latest/download/espup-x86_64-pc-windows-msvc.exe' -OutFile .\espup.exe
    .\espup.exe install

For Windows MSVC/GNU, Rust environment can also be installed with Universal Online idf-installer: https://dl.espressif.com/dl/esp-idf/

Windows x86_64 MSVC

The following instructions are specific for the ESP32 and ESP32-S series based on Xtensa architecture. If you do not have Visual Studio and Windows 10 SDK installed, consider the alternative option Windows x86_64 GNU.

Instructions for ESP-C series based on RISC-V architecture are described in RISC-V section.

Prerequisites x86_64 MSVC

Installation of prerequisites using Winget:

winget install --id Git.Git
winget install Python # requirements for ESP-IDF based development, skip in case of Bare metal
winget install -e --id Microsoft.WindowsSDK
winget install Microsoft.VisualStudio.2022.BuildTools --silent --override "--wait --quiet --add Microsoft.VisualStudio.Component.VC.Tools.x86.x64"

Installation of prerequisites using Visual Studio installer GUI - installed with option Desktop development with C++ - components: MSVCv142 - VS2019 C++ x86/64 build tools, Windows 11 SDK

Visual Studio Installer - configuration

Installation of MSVC and Windows 11 SDK using vs_buildtools.exe:

Invoke-WebRequest 'https://aka.ms/vs/17/release/vs_buildtools.exe' -OutFile .\vs_buildtools.exe
.\vs_BuildTools.exe --passive --wait --add Microsoft.VisualStudio.Component.VC.Tools.x86.x64 --add Microsoft.VisualStudio.Component.Windows10SDK.20348

Installation of prerequisites using Chocolatey (run PowerShell as Administrator):

Set-ExecutionPolicy Bypass -Scope Process -Force; [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.ServicePointManager]::SecurityProtocol -bor 3072; iex ((New-Object System.Net.WebClient).DownloadString('https://community.chocolatey.org/install.ps1'))
choco install visualstudio2022-workload-vctools windows-sdk-10.0 -y
choco install cmake git ninja python3 -y  # requirements for ESP-IDF based development, skip in case of Bare metal

Main installation:

Invoke-WebRequest 'https://github.com/esp-rs/espup/releases/latest/download/espup-x86_64-pc-windows-msvc.exe' -OutFile .\espup.exe
.\espup.exe install

Windows x86_64 GNU

The following instructions describe deployment with the GNU toolchain. If you're using Visual Studio with Windows 10 SDK, consider option Windows x86_64 MSVC.

Prerequisites x86_64 GNU

Install MinGW x86_64 e.g., from releases https://github.com/niXman/mingw-builds-binaries/releases and add bin to environment variable PATH

choco install 7zip -y
Invoke-WebRequest https://github.com/niXman/mingw-builds-binaries/releases/download/12.1.0-rt_v10-rev3/x86_64-12.1.0-release-posix-seh-rt_v10-rev3.7z -OutFile x86_64-12.1.0-release-posix-seh-rt_v10-rev3.7z
7z x x86_64-12.1.0-release-posix-seh-rt_v10-rev3.7z
$env:PATH+=";.....\x86_64-12.1.0-release-posix-seh-rt_v10-rev3\mingw64\bin"

Main installation:

Invoke-WebRequest 'https://github.com/esp-rs/espup/releases/latest/download/espup-x86_64-pc-windows-msvc.exe' -OutFile .\espup.exe
.\espup.exe install

RISC-V Installation

The following instructions are specific for ESP32-C based on RISC-V architecture.

Install the RISC-V target for Rust:

rustup target add riscv32imc-unknown-none-elf

Building projects

Cargo first approach

  1. Install cargo-generate

    cargo install cargo-generate
  2. Generate project from template with one of the following templates

    # STD Project
    cargo generate esp-rs/esp-idf-template cargo
    # NO-STD (Bare-metal) Project
    cargo generate esp-rs/esp-template

To understand the differences between the two ecosystems, see Ecosystem Overview chapter of the book. There is also a Chapter that explains boths template projects:

  1. Build and flash:

    cargo espflash flash <SERIAL>

    Where SERIAL is the serial port connected to the target device.

    cargo-espflash also allows opening a serial monitor after flashing with --monitor option.

    If no SERIAL argument is used, cargo-espflash will print a list of the connected devices, so the user can choose which one to flash.

    See Usage section for more information about arguments.

    If espflash is installed (cargo install espflash), cargo run will build, flash the device, and open a serial monitor.

If you are looking for inspiration or more complext projects see:

Idf first approach

When building for Xtensa targets, we need to override the esp toolchain, there are several solutions: - Set esp toolchain as default: rustup default esp - Use cargo +esp - Override the project directory: rustup override set esp - Create a file called rust-toolchain.toml or rust-toolchain with: toml [toolchain] channel = "esp"

  1. Get example source code

    git clone https://github.com/espressif/rust-esp32-example.git
    cd rust-esp32-example-main
  2. Select architecture for the build

    idf.py set-target <TARGET>

    Where TARGET can be:

    • esp32 for the ESP32(Xtensa architecture). [Default]
    • esp32s2 for the ESP32-S2(Xtensa architecture).
    • esp32s3 for the ESP32-S3(Xtensa architecture).
  3. Build and flash

    idf.py build flash

Using Containers

Alternatively, some container images with pre-installed Rust and ESP-IDF, are published to Dockerhub and can be used to build Rust projects for ESP boards:

Podman example with mapping multiple /dev/ttyUSB from host computer to the container:

podman run --device /dev/ttyUSB0 --device /dev/ttyUSB1 -it docker.io/espressif/idf-rust-examples

Docker (does not support flashing from a container):

docker run -it espressif/idf-rust-examples

If you are using the idf-rust-examples image, instructions will be displayed on the screen.

Using Dev Containers

Dev Container support is offered for VS Code, Gitpod, and GitHub Codespaces, resulting in a fully working environment to develop for ESP boards in Rust, flash and simulate projects with Wokwi from the container.

Template projects esp-template and esp-idf-template include a question for Dev Containers support.

Release process

Before beginning preparation for a new release create branch build/X.Y.Z.W where X.Y.Z matches Rust release number and W is build number assigned by esp-rs. W has a tendency to be in the range 0-2 during one release.

On the branch change all version numbers from the previous release to the new one using replace function (e.g. in VS Code). Examples of replace: 1.63.0.1 -> 1.64.0.0. Commit files including CI files to the branch.

Building release

All build operations must be performed on custom runners, because of large storage required by the build process. Check Settings that all runners are online.

Perform custom dispatch. Change branch to build/X.Y.Z.W, change Branch of rust-build to us to build/X.Y.Z.W:

Once all things are in place, also upload the installer to releases:

Perform test jobs.

Send notification to Matrix channel about the pre-release.

Finalization of release (about 2-3 days later)

Edit Release, turn off Pre-release flag, and Save

Send notification to Matrix channel about the pre-release.

Rollback release

Rollback of the release is possible when a significant bug occurs that damages the release for all platforms.

First rule: Do not panic. :-) Just mark the release as Pre-release in GitHub releases.

If build/X.Y.Z.W branch was already merged to main, change the default version in main to build/a.b.c.d where a.b.c.d corresponds to previously known working release. E.g. from build/1.63.0.1 to build/1.63.0.0.

Uploading new image tags to espressif/idf-rust

Once the release is ready, manually run the Publish IDF-Rust Tags workflow with:

  • Branch of rust-build to use pointing to main if the build/X.Y.Z.W branch was already merged to main, or pointing to build/X.Y.Z.W if has not been merged yet, but the branch is ready and feature complete.
  • Version of Rust toolchain should be X.Y.Z.W.

rust-build's People

Contributors

cameron-pascal avatar dependabot[bot] avatar georgik avatar ilmanzo avatar jenspfeifle avatar jessebraham avatar kevin-june avatar mabezdev avatar mykmelez avatar nicholas-l avatar playfulfence avatar regexident avatar sergiogasquez avatar stappersg avatar svenstaro avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

rust-build's Issues

Remove PIP_USER="yes"

Remove workaround PIP_USER="yes", because solution is now part of ESP-IDF:
espressif/esp-idf#7910

This environment variable was set on GitPod build machines and it was not possible to bootstrap the environment for ESP-IDF. The solution was applied to all release branches of ESP-IDF.

It's not clear if we still need to install ESP-IDF.

Both the esp book and this repository make no mention of requiring esp-idf, but it seems that the linker is still needed.

(It does look like it builds esp-idf, but in my current environment, it fails to build it.)

Installation script pollutes executing directory with installation artifacts

This isn't really a big deal, but would be nice if the installation script cleaned up after itself. Very much a "nice to have" feature. Currently following installation via the script, the following files and directories still exist in the executing directory:

jesse@mbp ~/temp
λ ll                                                                                                                                                                                                                                                                                                                                                               2022-04-07 09:27:36
total 170400
-rwxr-xr-x   1 jesse  staff   8.4K  7 Apr 09:01 install-rust-toolchain.sh*
drwxr-xr-x  17 jesse  staff   544B  7 Apr 09:02 rust-1.60.0.0-x86_64-apple-darwin/
-rw-r--r--   1 jesse  staff    80M  7 Apr 09:02 rust-1.60.0.0-x86_64-apple-darwin.tar.xz
drwxr-xr-x  12 jesse  staff   384B  7 Apr 09:02 rust-src-1.60.0.0/
-rw-r--r--   1 jesse  staff   2.6M  7 Apr 09:02 rust-src-1.60.0.0.tar.xz

Add cargo and rust fmt to the toolchain build

Hi,
I've been experimenting with my own build of the toolchain for a while now
https://github.com/esp-rs/rust

One of the things I've discovered is a unique bug associated with windows when using a linked / custom toolchain such as esp
Typically some tools such as "cargo make" or "rust-analyser" under visual studio code
tend to run cargo multiple times at the same time (similar to running it multithreaded)

If cargo isn't installed as part of the custom toolchain, then it tends to try and use the cargo native to the host.
But because of the way it does this, it tends to fail under windows when you try to run it more than once at the same time.

The best workaround I've found is to just install cargo into the custom toolchain

# Fixes VSCode Issues with rust-analyser / cargo-make
x.py build --stage 2 cargo

I also tend to add rustfmt for reformatting code

# Add rustfmt for reformatting code
x.py build --stage 2 rustfmt

Would there be any issues in adding these to the workflows script?
I think it would solve a lot of problems associated with rust-analyser and cargo make which are quite useful.

Ubuntu 22.04 is using openSSL 3.0 as default

When I install newest Ubuntu 22.04, I found that the version of openssl is 3.0. SO I occur the problem with rust-build.

~/.rustup/toolchains/esp-1.60.0.1/bin/cargo: error while loading shared libraries: libssl.so.1.1: cannot open shared object file: No such file or directory

Now I get a new Solution that compile the openssl 1.1.1. And add compiled openssl 1.1.1 to ld.so.conf. Can solve the problem temproarily.

Generate several tags for espressif/idf-rust Dockerhub image

Add CI, similar to the one in esp-rs-container, to publish in espressif/idf-rust several tags with different esp-idf versions and different boards installed. Tags should be available in linux/amd64 and linux/arm64.

For tags, the naming will be the following: <boards>_<xtensa>_<esp-idf>, where :

  • Boards installed in esp-idf: esp32, esp32c3, esp32s2, esp32s3 or all
  • Rust Xtensa toolchain version
  • Esp-Idf version: release/v4.4, master(v5.0)....

Check cargo-espflash version during installation

Check whether cargo-espflash has new version.
cargo install might fail on following error which results in keeping previous version e.g. v1.1.0

cargo install cargo-espflash
    Updating crates.io index
  Downloaded cargo-espflash v1.2.0
  Downloaded 1 crate (23.7 KB) in 0.35s
error: binary `cargo-espflash.exe` already exists in destination
Add --force to overwrite

Installing riscv32imc-esp-espidf does not work on Apple M1

I'm going through the esp-rs book trying to get a simple example working for my ESP32C3, but I'm unable to install the toolchain:

$ rustup target add riscv32imc-esp-espidf
error: toolchain 'nightly-aarch64-apple-darwin' does not contain component 'rust-std' for target 'riscv32imc-esp-espidf'
note: not all platforms have the standard library pre-compiled: https://doc.rust-lang.org/nightly/rustc/platform-support.html
help: consider using `cargo build -Z build-std` instead

I'm new-ish to Rust, so I'm not sure exactly how to avail myself of the "help" suggestion. Running cargo build -Z build-std shows

error: could not find `Cargo.toml` in `$PWD` or any parent directory

I checked the README of this repo and there is a link to a ESP32C3 document, but the link is broken (it leads to a 404).

Installation of espflash fails with error

Error message:

error[E0658]: exclusive range pattern syntax is experimental
  --> /home/georgik/.cargo/registry/src/github.com-1ecc6299db9ec823/espflash-1.1.0/src/chip/esp32/esp32c3.rs:85:53
   |
85 |             (ImageFormatId::DirectBoot, None | Some(3..)) => {

Reason: Version of Rust 1.54. Required version 1.55.

./install-rust-toolchain.sh: line 81: ./rust-src-1.55.0-dev/install.sh: No such file or directory

Just tried to reinstall rust toolchain.

./install-rust-toolchain.sh                                                                                                                                             
/Users/andres/.cargo/bin/rustc
rustfmt 1.4.37-stable (09c42c45 2021-10-18)
Installation of toolchain for x86_64-apple-darwin
** downloading: https://github.com/esp-rs/rust-build/releases/download/v1.55.0-dev/rust-1.55.0-dev-x86_64-apple-darwin.tar.xz
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   650  100   650    0     0   1577      0 --:--:-- --:--:-- --:--:--  1573
100  141M  100  141M    0     0  5682k      0  0:00:25  0:00:25 --:--:-- 5852k
install: creating uninstall script at /Users/andres/.rustup/toolchains/esp/lib/rustlib/uninstall.sh
install: installing component 'rustc'
install: installing component 'cargo'
install: installing component 'clippy-preview'
install: installing component 'rls-preview'
install: installing component 'rust-analyzer-preview'
install: installing component 'miri-preview'
install: installing component 'rustfmt-preview'
install: installing component 'llvm-tools-preview'
install: installing component 'rust-analysis-x86_64-apple-darwin'
install: installing component 'rust-std-x86_64-apple-darwin'

    rust installed.

./install-rust-toolchain.sh: line 81: ./rust-src-1.55.0-dev/install.sh: No such file or directory
ls -ltr                                                                                                                                                        49s  ●  ~/D/y/rust-build
total 238424
drwxr-xr-x 21 andres staff       672 Sep 15 17:39 rust-1.55.0-dev-x86_64-apple-darwin
-rw-r--r--  1 andres staff       324 Oct 20 15:44 Dockerfile
-rw-r--r--  1 andres staff      3488 Oct 20 15:44 Install-RustToolchain.ps1
-rw-r--r--  1 andres staff      1063 Oct 20 15:44 LICENSE
-rw-r--r--  1 andres staff      3362 Oct 20 15:44 README.md
-rwxr-xr-x  1 andres staff      3579 Oct 20 15:44 install-rust-toolchain.sh
drwxr-xr-x  3 andres staff        96 Oct 20 15:44 support
-rw-r--r--  1 andres staff   2429160 Oct 20 15:50 rust-src-1.55.0-dev.tar.xz
-rw-r--r--  1 andres staff  89895320 Oct 20 15:52 xtensa-esp32-elf-llvm12_0_1-esp-12.0.1-20210823-macos.tar.xz
-rw-r--r--  1 andres staff     21569 Oct 20 16:18 main.zip
-rw-r--r--  1 andres staff 148715876 Oct 22 16:14 rust-1.55.0-dev-x86_64-apple-darwin.tar.xz

Add clippy

Request: add clippy back to the binary release as compiling from source depends on rustc-dev crate which as well is not distributed at the moment. Using clippy from the default toolchain causes the problem that it is not working together with --target

Incomplete installation instructions and script issue

Hello,

First, thanks a lot for the effort to get Rust working for Espressif devices. These are suggestions to have the installation process a bit smoother.

  1. Installation instructions

From the installation instruction, it is not clear whether the ESP-IDF framework needs to be installed or not and which version is supported. When trying the command idf.py set-target esp32, the system can't find it. There must be something lacking in the exports for the PATH.

  1. End of script update to .zshrc

I'm using Ubuntu 20.4. Bash is the standard shell. As there are no .zshrc in the user's main folder, the updates on PATH and other env variables are not done. It would be handy to have the .bashrc and .profile automatically updated in this context. Or say so in some output text to help newbies like me do it by hand.

Thanks again!
Guy

Rustc 1.56.0.1 fails with SIGABRT on macOS Monterey x86_64

Error:

error: could not compile `core`
Caused by:
  process didn't exit successfully: `rustc --crate-name core --edition=2018 /Users/user/.rustup/toolchains/esp/lib/rustlib/src/rust/library/core/src/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts --crate-type lib --emit=dep-info,metadata,link -C opt-level=1 -C embed-bitcode=no -C debuginfo=2 -C debug-assertions=on --cfg 'feature="panic_immediate_abort"' -C metadata=ebd3b023ebdd7018 -C extra-filename=-ebd3b023ebdd7018 --out-dir /Users/user/Workspace/ESP32/esp32-hello-rust/rustlib/target/xtensa-esp32-none-elf/debug/deps --target xtensa-esp32-none-elf -Z force-unstable-if-unmarked -L dependency=/Users/user/Workspace/ESP32/esp32-hello-rust/rustlib/target/xtensa-esp32-none-elf/debug/deps -L dependency=/Users/user/Workspace/ESP32/esp32-hello-rust/rustlib/target/debug/deps --cap-lints allow` (signal: 6, SIGABRT: process abort signal)
warning: build failed, waiting for other jobs to finish...
error: build failed

Research dependency of toolchains nightly and stable

Right now we deploy stable, nightly and our toolchain for building ESP32 target.
Investigate, whether this is really necessary and whether the build can work even without nightly and stable.
Verify changes by running test-rust-installer.sh.

Add CC and AR variables of compiler name to generated export script

The variable export script currently has this content more or less:

export PATH="/home/svenstaro/.espressif/tools/xtensa-esp32-elf-clang/esp-13.0.0-20211203-x86_64-unknown-linux-gnu/bin/:$PATH"
export LIBCLANG_PATH="/home/svenstaro/.espressif/tools/xtensa-esp32-elf-clang/esp-13.0.0-20211203-x86_64-unknown-linux-gnu/lib/"
export PIP_USER=no

This will currently make build.rs-driven cross-compilation impossible since the CC and AR are unset and so a crate such as cc will still use the host's regular cc and ar commands.

Consider this simple build.rs:

fn main() -> anyhow::Result<()> {
    println!("cargo:rerun-if-changed=c/hello.c");
    println!("cargo:rerun-if-changed=target/export-esp-rust.sh");
    cc::Build::new()
        .file("c/hello.c")
        .compile("hello");

    embuild::build::CfgArgs::output_propagated("ESP_IDF")?;
    embuild::build::LinkArgs::output_propagated("ESP_IDF")
}

This won't compile properly as it stands right now because of the aforementioned reason. I suggest expanding the exported variables to include all of the cross compilation toolchain tools.

In fact, I wonder why this is not being done and whether I'm missing something here.

Consider this:

export CC="xtensa-esp32-elf-gcc"
export AR="xtensa-esp32-elf-ar"
export PATH="/home/svenstaro/.espressif/tools/xtensa-esp32-elf-clang/esp-13.0.0-20211203-x86_64-unknown-linux-gnu/bin/:$PATH"
export LIBCLANG_PATH="/home/svenstaro/.espressif/tools/xtensa-esp32-elf-clang/esp-13.0.0-20211203-x86_64-unknown-linux-gnu/lib/"
export PIP_USER=no

Would allow you to compile and link most simple C programs directly and without further hassle. What do you think?

No usable xtensa compiler is installed

The recent merge and release of 0549a1a has disabled the installation of gcc while also not installing any usable other compilers for xtensa. The installation of Clang uses a custom minimal build with only libs and no binaries. I think rust-build should just use the upstream Clang compiler which could reduce complexity (as it'd just depend on upstream).

This ties in with my earlier observation in #85.

At the same time, there are still some unused gcc variables left in the installation script.

Shrink LLVM artifact to minimal size

Rust compiler does not need whole llvm-project artifact.
Smaller artifact can make images and deployment smaller which leads to quick container spin-up and smaller footprint in registries.
Research options to shrink the artifact.

If `$CARGO_HOME` is set, installation script tries to source potentially non-existent file

The script currently does this:

        if [ ! -z "${CARGO_HOME}" ]; then
            source ${CARGO_HOME}/env
        else

So it assumes that ${CARGO_HOME}/env exists just because ${CARGO_HOME} is set. This crashes my current environment and I have to create a env file just for this script not to choke. It'd be nice if the script also checked for actual existence of that file before blindly sourcing it.

Add install-rust-toolchain.sh to release artifacts

I think it would be helpful to add the install-rust-toolchain.sh installer script to the release artifacts. This would make it easier to automate the process of installing the binary toolchains by simply downloading and then running the installer script. This would allow individual users to install the toolchain without needing to check out the source repository first.

Update of custom toolchain using rustup

Scenario: User deployed toolchain 1.56.0.0 and later on user wants upgrade to 1.59.0.0
The installation script does not display any warning an quits.

Workaround:

  • run installation with parameter -i: ./install-rust-toolchain.sh -i reinstall
  • or delete ~/.rustup/toolchains/esp

Expected behavior: Installer allows updated of the toolchain in the similar way like rustup

Stack overflow, despite not doing anything crazy?

Hi, me and my partner have been trying to run our project on a esp32 wroom.

So far, w're trying to run this project. There is a certain line, where one of our dependencies use serde_cbor to serialize an object, the function looks like this:


    pub fn generate_message_1(
        self,
        r#type: isize,
        suites: isize,
    ) -> Result<(Vec<u8>, PartyI<Msg2Receiver>), EarlyError> {
        // Encode the necessary informati'on into the first message
        let msg_1 = Message1 {
            r#type,
            suite: suites,
            x_i: self.0.x_i.as_bytes().to_vec(), // sending PK as vector
            c_i: self.0.c_i,
        };
        // Get CBOR sequence for message
        let msg_1_seq = util::serialize_message_1(&msg_1)?;
        // Copy for returning
        let msg_1_bytes = msg_1_seq.clone();

        Ok((
            msg_1_bytes,
            PartyI(Msg2Receiver {
                i_ecdh_ephemeralsecret: self.0.secret,
                stat_priv: self.0.static_secret,
                stat_pub: self.0.static_public,
      //          auth: self.0.auth,
                kid: self.0.kid,
                msg_1_seq,
            }),
        ))
    }
}

And the serialization function that is lastly called looks like this:


fn serialize(object: impl Serialize, offset: usize) -> Vec<u8> {
    // Serialize to byte vector
    let mut v = serde_cbor::to_vec(&object).expect("error during serialization");
    // Return everything starting from the offset
    v.drain(offset..).collect()
}

I might not be super helpfull to include the code, but I thought I would do it anyway.

Anyways, this runs with no issues on our own machines, but as soon as we try to flash it onto our ESP32 wroom, this happens:

***ERROR*** A stack overflow in task main has been detected.
Backtrace:0x40081a36:0x3ffb63d00x40084d21:0x3ffb63f0 0x40087476:0x3ffb6410 0x40086309:0x3ffb6490 0x40084e20:0x3ffb64c0 0x40084dd2:0x3ffb64f0 0x400e9735:0x00000004  |<-CORRUPTED
ELF file SHA256: 0000000000000000

We should have 520KB disposable, and in my mind, what we're doing here should definitely not overflow that.

Is there any configurations that one can do to access more ram on the device? or what is this likely to be caused by? it seems very unlikely to me that what were doing now overfills 520 kb

SIGABRT: Failed to compile `clap v2.34.0` (on `rust-esp32-std-demo`)

Cloning the example and compiling on macOS Monterey 12.0.1 with the esp toolchain fails when building clap v2.34.0:

error: could not compile `clap`

Caused by:
  process didn't exit successfully: `rustc --crate-name clap --edition=2018 /Users/thorcorreia/.cargo/registry/src/github.com-1ecc6299db9ec823/clap-2.34.0/src/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts --crate-type lib --emit=dep-info,metadata,link -C embed-bitcode=no -C split-debuginfo=unpacked -C debuginfo=2 --cfg 'feature="ansi_term"' --cfg 'feature="atty"' --cfg 'feature="color"' --cfg 'feature="default"' --cfg 'feature="strsim"' --cfg 'feature="suggestions"' --cfg 'feature="vec_map"' -C metadata=ac26a8e48a625ff4 -C extra-filename=-ac26a8e48a625ff4 --out-dir /Users/thorcorreia/Dev/rust-esp32-std-demo/target/debug/deps -L dependency=/Users/thorcorreia/Dev/rust-esp32-std-demo/target/debug/deps --extern ansi_term=/Users/thorcorreia/Dev/rust-esp32-std-demo/target/debug/deps/libansi_term-7bb5c8085badc50a.rmeta --extern atty=/Users/thorcorreia/Dev/rust-esp32-std-demo/target/debug/deps/libatty-02f4983f38003a7d.rmeta --extern bitflags=/Users/thorcorreia/Dev/rust-esp32-std-demo/target/debug/deps/libbitflags-45b4e505e2497911.rmeta --extern strsim=/Users/thorcorreia/Dev/rust-esp32-std-demo/target/debug/deps/libstrsim-2b74c9109d8bb938.rmeta --extern textwrap=/Users/thorcorreia/Dev/rust-esp32-std-demo/target/debug/deps/libtextwrap-9684b827efe0b904.rmeta --extern unicode_width=/Users/thorcorreia/Dev/rust-esp32-std-demo/target/debug/deps/libunicode_width-d208e9921c947bc5.rmeta --extern vec_map=/Users/thorcorreia/Dev/rust-esp32-std-demo/target/debug/deps/libvec_map-63037abaf65b04ec.rmeta --cap-lints allow` (signal: 6, SIGABRT: process abort signal)

It appears that the esp toolchain is unable to compile clap for some reason.

Edit: running the rustc command yields:

rustc(41908,0x7000083ca000) malloc: *** error for object 0x600002596000: pointer being realloc'd was not allocated

set release-channel=nightly for builds

We should set --release-channel=nightly when configuring our compiler builds. I.e ./configure --experimental-targets=Xtensa --release-channel=nightly

Before:

rustc +esp-dev --version --verbose
rustc 1.59.0 (04e60933c 2022-03-14)
binary: rustc
commit-hash: unknown
commit-date: unknown
host: x86_64-unknown-linux-gnu
release: 1.59.0
LLVM version: 13.0.0

After:

rustc +esp-dev --version --verbose
rustc 1.59.0 (04e60933c 2022-03-14)
binary: rustc
commit-hash: 04e60933cbe54af30d339efd67da6b43016433ad
commit-date: 2022-03-14
host: x86_64-unknown-linux-gnu
release: 1.59.0
LLVM version: 13.0.0

Unable to build `rust-esp32-std-demo` using Docker and cargo

Hello!

I seem unable to build rust-esp32-std-demo using the Docker image espressif/idf-rust-examples:latest (image ID 562dd6cc6e54) using cargo. The issue seems to be related to PlatformIO. Builds using idf.py build work fine.

The host machine is an Intel-Mac running macOS Big Sur v11.2.3.

Suggestions?

Relevant logs:

docker run -it espressif/idf-rust-examples
Detecting the Python interpreter
Checking "python" ...
Python 3.8.10
"python" has been detected
Adding ESP-IDF tools to PATH...
Not using an unsupported version of tool xtensa-esp32-elf found in PATH: esp-2021r1-8.4.0.
Using Python interpreter in /opt/esp/python_env/idf5.0_py3.8_env/bin/python
Checking if Python packages are up to date...
Python requirements from /opt/esp/idf/requirements.txt are satisfied.
Added the following directories to PATH:
  /opt/esp/idf/components/esptool_py/esptool
  /opt/esp/idf/components/espcoredump
  /opt/esp/idf/components/partition_table
  /opt/esp/idf/components/app_update
  /opt/esp/tools/xtensa-esp32-elf/esp-2021r2-8.4.0/xtensa-esp32-elf/bin
  /opt/esp/tools/xtensa-esp32s2-elf/esp-2021r2-8.4.0/xtensa-esp32s2-elf/bin
  /opt/esp/tools/xtensa-esp32s3-elf/esp-2021r2-8.4.0/xtensa-esp32s3-elf/bin
  /opt/esp/tools/riscv32-esp-elf/esp-2021r2-8.4.0/riscv32-esp-elf/bin
  /opt/esp/tools/esp32ulp-elf/2.28.51-esp-20191205/esp32ulp-elf-binutils/bin
  /opt/esp/tools/esp32s2ulp-elf/2.28.51-esp-20191205/esp32s2ulp-elf-binutils/bin
  /opt/esp/tools/cmake/3.20.3/bin
  /opt/esp/tools/openocd-esp32/v0.10.0-esp32-20211111/openocd-esp32/bin
  /opt/esp/python_env/idf5.0_py3.8_env/bin
  /opt/esp/idf/tools
Done! You can now compile ESP-IDF projects.
Go to the project directory and run:

  idf.py build

==============================================================================
=           Docker image with ESP-IDF, Rust compiler and examples            =
=              https://github.com/espressif/rust-esp32-example               =
==============================================================================

Available examples:

* "cargo-first" approach
  `` ``` ``sh
    cd /opt/rust-esp32-std-demo
    cargo +esp build --release
    espflash /dev/ttyUSB0 target/xtensa-esp32-espidf/release/rust-esp32-std-demo
    cargo pio espidf monitor -e release /dev/ttyUSB0
  `` ``` ``

* "idf.py-first" approach - integration via CMake files
  `` ``` ``sh
    cd /opt/rust-esp32-example
    idf.py build
  `` ``` ``
root@918e12cae58c:/opt# cd rust-esp32-std-demo
root@918e12cae58c:/opt/rust-esp32-std-demo# export set RUST_BACKTRACE=1 && cargo +esp build --release
warning: unused config key `unstable.configurable-env` in `/opt/rust-esp32-std-demo/.cargo/config.toml`
warning: unused config key `unstable.extra-link-arg` in `/opt/rust-esp32-std-demo/.cargo/config.toml`
   Compiling compiler_builtins v0.1.49
   Compiling core v0.0.0 (/opt/rustup/toolchains/esp/lib/rustlib/src/rust/library/core)
   Compiling libc v0.2.103
   Compiling cc v1.0.69
   Compiling std v0.0.0 (/opt/rustup/toolchains/esp/lib/rustlib/src/rust/library/std)
   Compiling libc v0.2.109
   Compiling memchr v2.4.1
   Compiling proc-macro2 v1.0.33
   Compiling unicode-xid v0.2.2
   Compiling syn v1.0.82
   Compiling cfg-if v1.0.0
   Compiling cc v1.0.72
   Compiling log v0.4.14
   Compiling autocfg v1.0.1
   Compiling serde_derive v1.0.130
   Compiling serde v1.0.130
   Compiling fnv v1.0.7
   Compiling once_cell v1.8.0
   Compiling ryu v1.0.6
   Compiling spin v0.5.2
   Compiling untrusted v0.7.1
   Compiling regex-syntax v0.6.25
   Compiling serde_json v1.0.72
   Compiling version_check v0.9.3
   Compiling anyhow v1.0.51
   Compiling tinyvec_macros v0.1.0
   Compiling glob v0.3.0
   Compiling crossbeam-utils v0.8.5
   Compiling matches v0.1.9
   Compiling lazy_static v1.4.0
   Compiling adler v1.0.2
   Compiling ppv-lite86 v0.2.15
   Compiling gimli v0.26.1
   Compiling unicode-width v0.1.9
   Compiling bitflags v1.3.2
   Compiling percent-encoding v2.1.0
   Compiling same-file v1.0.6
   Compiling unicode-bidi v0.3.7
   Compiling ansi_term v0.12.1
   Compiling vec_map v0.8.2
   Compiling termcolor v1.1.2
   Compiling rustc-demangle v0.1.21
   Compiling bindgen v0.57.0
   Compiling humantime v2.1.0
   Compiling strsim v0.8.0
   Compiling shlex v0.1.1
   Compiling itoa v0.4.8
   Compiling peeking_take_while v0.1.2
   Compiling lazycell v1.3.0
   Compiling zero v0.1.2
   Compiling either v1.6.1
   Compiling chunked_transfer v1.4.0
   Compiling base64 v0.13.0
   Compiling rustc-hash v1.1.0
   Compiling remove_dir_all v0.5.3
   Compiling unicode-segmentation v1.8.0
   Compiling shlex v1.1.0
   Compiling futures-core v0.3.18
   Compiling strsim v0.10.0
   Compiling ident_case v1.0.1
   Compiling az v1.2.0
   Compiling async-trait v0.1.51
   Compiling paste v1.0.6
   Compiling heapless v0.7.8
   Compiling unwind v0.0.0 (/opt/rustup/toolchains/esp/lib/rustlib/src/rust/library/unwind)
   Compiling libloading v0.7.2
   Compiling cmake v0.1.46
   Compiling backtrace v0.3.63
   Compiling ring v0.16.20
   Compiling miniz_oxide v0.4.4
   Compiling num-traits v0.2.14
   Compiling thread_local v1.1.3
   Compiling rustc-std-workspace-core v1.99.0 (/opt/rustup/toolchains/esp/lib/rustlib/src/rust/library/rustc-std-workspace-core)
   Compiling nom v5.1.2
   Compiling tinyvec v1.5.1
   Compiling clang-sys v1.3.0
   Compiling textwrap v0.11.0
   Compiling form_urlencoded v1.0.1
   Compiling walkdir v2.3.2
   Compiling addr2line v0.17.0
   Compiling xmas-elf v0.8.0
   Compiling heck v0.3.3
   Compiling unicode-normalization v0.1.19
   Compiling getrandom v0.2.3 (https://github.com/esp-rs-compat/getrandom.git#b8cb133e)
   Compiling atty v0.2.14
   Compiling dirs-sys v0.3.6
   Compiling which v3.1.1
   Compiling which v4.2.2
   Compiling remove_dir_all v0.7.0
   Compiling aho-corasick v0.7.18
   Compiling bstr v0.2.17
   Compiling object v0.27.1
   Compiling quote v1.0.10
   Compiling alloc v0.0.0 (/opt/rustup/toolchains/esp/lib/rustlib/src/rust/library/alloc)
   Compiling cfg-if v0.1.10
   Compiling rand_core v0.6.3
   Compiling clap v2.34.0
   Compiling dirs v4.0.0
   Compiling idna v0.2.3
   Compiling regex v1.5.4
   Compiling rustc-std-workspace-alloc v1.99.0 (/opt/rustup/toolchains/esp/lib/rustlib/src/rust/library/rustc-std-workspace-alloc)
   Compiling panic_abort v0.0.0 (/opt/rustup/toolchains/esp/lib/rustlib/src/rust/library/panic_abort)
   Compiling webpki v0.22.0
   Compiling sct v0.7.0
   Compiling cexpr v0.4.0
   Compiling rand_chacha v0.3.1
   Compiling url v2.2.2
   Compiling globset v0.4.8
   Compiling env_logger v0.8.4
   Compiling darling_core v0.13.0
   Compiling panic_unwind v0.0.0 (/opt/rustup/toolchains/esp/lib/rustlib/src/rust/library/panic_unwind)
   Compiling std_detect v0.1.5 (/opt/rustup/toolchains/esp/lib/rustlib/src/rust/library/stdarch/crates/std_detect)
   Compiling hashbrown v0.11.0
   Compiling webpki-roots v0.22.1
   Compiling rustls v0.20.2
   Compiling rand v0.8.4
   Compiling ignore v0.4.18
   Compiling strum_macros v0.21.1
   Compiling thiserror-impl v1.0.30
   Compiling derivative v2.2.0
   Compiling ureq v2.3.1
   Compiling darling_macro v0.13.0
   Compiling tempfile v3.2.0
   Compiling globwalk v0.8.1
   Compiling strum v0.21.0
   Compiling thiserror v1.0.30
   Compiling proc_macro v0.0.0 (/opt/rustup/toolchains/esp/lib/rustlib/src/rust/library/proc_macro)
   Compiling darling v0.13.0
   Compiling nb v1.0.0
   Compiling void v1.0.2
   Compiling cache-padded v1.1.1
   Compiling waker-fn v1.1.0
   Compiling byteorder v1.4.3
   Compiling parking v2.0.0
   Compiling futures-io v0.3.18
   Compiling pin-project-lite v0.2.7
   Compiling fastrand v1.5.0
   Compiling event-listener v2.5.1
   Compiling display-interface v0.4.1
   Compiling async-task v4.0.3
   Compiling base64 v0.12.3
   Compiling slab v0.4.5
   Compiling atomic-waker v1.0.0
   Compiling mutex-trait v0.2.0
   Compiling byte-slice-cast v0.3.5
   Compiling cty v0.2.2
   Compiling stable_deref_trait v1.2.0
   Compiling micromath v1.1.1
   Compiling toml v0.5.8
   Compiling enumset_derive v0.5.5
   Compiling socket2 v0.4.2 (https://github.com/esp-rs-compat/socket2#7217ebe8)
   Compiling nb v0.1.3
   Compiling concurrent-queue v1.2.2
   Compiling hash32 v0.2.1
   Compiling no-std-net v0.5.0
   Compiling futures-lite v1.12.0
   Compiling async-lock v2.4.0
   Compiling http-auth-basic v0.1.3
   Compiling embedded-graphics-core v0.3.3
   Compiling cstr_core v0.2.4
   Compiling float-cmp v0.8.0
   Compiling cargo_toml v0.9.2
   Compiling proc-macro-crate v1.1.0
   Compiling enumset v1.0.8
   Compiling polling v2.1.0 (https://github.com/esp-rs-compat/polling#260dded7)
   Compiling embedded-hal v0.2.6
   Compiling async-channel v1.6.1
   Compiling async-executor v1.4.1
   Compiling embedded-graphics v0.7.1
   Compiling embuild v0.25.4
   Compiling num_enum_derive v0.5.4
   Compiling async-io v1.6.0
   Compiling display-interface-i2c v0.4.0
   Compiling display-interface-spi v0.4.1
   Compiling ili9341 v0.5.0 (https://github.com/yuri91/ili9341-rs#8aeefc4a)
   Compiling blocking v1.1.0
   Compiling st7789 v0.6.1
   Compiling num_enum v0.5.4
   Compiling ssd1306 v0.7.0
   Compiling esp-idf-sys v0.27.0
   Compiling esp-idf-hal v0.27.0
   Compiling esp-idf-svc v0.32.3
   Compiling rust-esp32-std-demo v0.20.6 (/opt/rust-esp32-std-demo)
   Compiling async-fs v1.5.0
   Compiling async-net v1.6.1
   Compiling embedded-svc v0.15.3
   Compiling smol v1.2.5 (https://github.com/esp-rs-compat/smol#b9a770e7)
error: failed to run custom build command for `esp-idf-sys v0.27.0`

Caused by:
  process didn't exit successfully: `/opt/rust-esp32-std-demo/target/release/build/esp-idf-sys-4c914487a370c77f/build-script-build` (exit status: 1)
  --- stdout
  Installer version: 1.0.2
  Platform: Linux-5.10.47-linuxkit-x86_64-with-glibc2.29
  Python version: 3.8.10 (default, Sep 28 2021, 16:10:42) 
  [GCC 9.3.0]
  Python path: /opt/esp/python_env/idf5.0_py3.8_env/bin/python3
  Creating a virtual environment at /root/.platformio/penv
  Updating Python package manager (PIP) in a virtual environment
  PIP has been successfully updated!
  Virtual environment has been successfully created!
  Installing PlatformIO Core
  Collecting platformio
    Downloading platformio-5.2.4.tar.gz (219 kB)
    Preparing metadata (setup.py): started
    Preparing metadata (setup.py): finished with status 'done'
  Collecting bottle==0.12.*
    Using cached bottle-0.12.19-py3-none-any.whl (89 kB)
  Collecting click!=8.0.2,<9,>=8
    Using cached click-8.0.3-py3-none-any.whl (97 kB)
  Collecting colorama
    Using cached colorama-0.4.4-py2.py3-none-any.whl (16 kB)
  Collecting marshmallow<4,>=2
    Using cached marshmallow-3.14.1-py3-none-any.whl (47 kB)
  Collecting pyelftools<1,>=0.27
    Using cached pyelftools-0.27-py2.py3-none-any.whl (151 kB)
  Collecting pyserial==3.*
    Using cached pyserial-3.5-py2.py3-none-any.whl (90 kB)
  Collecting requests==2.*
    Using cached requests-2.26.0-py2.py3-none-any.whl (62 kB)
  Collecting semantic_version==2.8.*
    Using cached semantic_version-2.8.5-py2.py3-none-any.whl (15 kB)
  Collecting tabulate==0.8.*
    Using cached tabulate-0.8.9-py3-none-any.whl (25 kB)
  Collecting zeroconf==0.37.*
    Downloading zeroconf-0.37.0-py3-none-any.whl (105 kB)
  Collecting aiofiles==0.8.*
    Downloading aiofiles-0.8.0-py3-none-any.whl (13 kB)
  Collecting ajsonrpc==1.*
    Using cached ajsonrpc-1.2.0-py3-none-any.whl (22 kB)
  Collecting starlette==0.17.*
    Using cached starlette-0.17.1-py3-none-any.whl (58 kB)
  Collecting uvicorn==0.16.*
    Downloading uvicorn-0.16.0-py3-none-any.whl (54 kB)
  Collecting wsproto==1.0.*
    Using cached wsproto-1.0.0-py3-none-any.whl (24 kB)
  Collecting charset-normalizer~=2.0.0
    Using cached charset_normalizer-2.0.9-py3-none-any.whl (39 kB)
  Collecting urllib3<1.27,>=1.21.1
    Using cached urllib3-1.26.7-py2.py3-none-any.whl (138 kB)
  Collecting certifi>=2017.4.17
    Using cached certifi-2021.10.8-py2.py3-none-any.whl (149 kB)
  Collecting idna<4,>=2.5
    Using cached idna-3.3-py3-none-any.whl (61 kB)
  Collecting anyio<4,>=3.0.0
    Using cached anyio-3.4.0-py3-none-any.whl (78 kB)
  Collecting h11>=0.8
    Using cached h11-0.12.0-py3-none-any.whl (54 kB)
  Collecting asgiref>=3.4.0
    Using cached asgiref-3.4.1-py3-none-any.whl (25 kB)
  Collecting ifaddr>=0.1.7
    Using cached ifaddr-0.1.7-py2.py3-none-any.whl (10 kB)
  Collecting sniffio>=1.1
    Using cached sniffio-1.2.0-py3-none-any.whl (10 kB)
  Building wheels for collected packages: platformio
    Building wheel for platformio (setup.py): started
    Building wheel for platformio (setup.py): finished with status 'done'
    Created wheel for platformio: filename=platformio-5.2.4-py3-none-any.whl size=344394 sha256=e08ce5c25916b31c0479140b215d83dc9897e657b1a1122bf75fbc3947cf894d
    Stored in directory: /root/.cache/pip/wheels/c7/5f/eb/2b681c5612c9a8ace53548f7febbd3edd52d6522ebfe2aafcc
  Successfully built platformio
  Installing collected packages: sniffio, idna, urllib3, ifaddr, h11, click, charset-normalizer, certifi, asgiref, anyio, zeroconf, wsproto, uvicorn, tabulate, starlette, semantic-version, requests, pyserial, pyelftools, marshmallow, colorama, bottle, ajsonrpc, aiofiles, platformio
  Successfully installed aiofiles-0.8.0 ajsonrpc-1.2.0 anyio-3.4.0 asgiref-3.4.1 bottle-0.12.19 certifi-2021.10.8 charset-normalizer-2.0.9 click-8.0.3 colorama-0.4.4 h11-0.12.0 idna-3.3 ifaddr-0.1.7 marshmallow-3.14.1 platformio-5.2.4 pyelftools-0.27 pyserial-3.5 requests-2.26.0 semantic-version-2.8.5 sniffio-1.2.0 starlette-0.17.1 tabulate-0.8.9 urllib3-1.26.7 uvicorn-0.16.0 wsproto-1.0.0 zeroconf-0.37.0

  PlatformIO Core has been successfully installed into an isolated environment `/root/.platformio/penv`!

  The full path to `platformio.exe` is `/root/.platformio/penv/bin/platformio`

  If you need an access to `platformio.exe` from other applications, please install Shell Commands
  (add PlatformIO Core binary directory `/root/.platformio/penv/bin` to the system environment PATH variable):

  See https://docs.platformio.org/page/installation.html#install-shell-commands

  Found compatible PlatformIO Core 5.2.4 -> /root/.platformio/penv/bin/platformio

  --- stderr
  Error: Compatible PlatformIO Core not found.
  Reason: PlatformIO Core was installed using another platform `Linux-5.11.0-1021-azure-x86_64-with-glibc2.29`. Your current platform: Linux-5.10.47-linuxkit-x86_64-with-glibc2.29
  Error: invalid type: null, expected a string at line 1 column 9390

  Stack backtrace:
     0: anyhow::error::<impl core::convert::From<E> for anyhow::Error>::from
     1: <core::result::Result<T,F> as core::ops::try_trait::FromResidual<core::result::Result<core::convert::Infallible,E>>>::from_residual
     2: embuild::pio::Pio::json
     3: embuild::pio::Pio::frameworks
     4: embuild::pio::Resolver::resolve_platform_all
     5: embuild::pio::Resolver::resolve
     6: build_script_build::build_driver::build
     7: build_script_build::main
     8: core::ops::function::FnOnce::call_once
     9: std::sys_common::backtrace::__rust_begin_short_backtrace
    10: std::rt::lang_start::{{closure}}
    11: std::rt::lang_start_internal
    12: std::rt::lang_start
    13: main
    14: __libc_start_main
    15: _start

Atomic operations unavaliable on esp8266 chips

When compiling with the toolchain installed through this tool, any code that uses the atomic instructions for fetch_add or other similar ones the linker will error out

undefined reference to `__sync_fetch_and_add_4'

Through much searching I am unable to track down where or how I would inform the linker of these symbols or where in my installation I am missing something that would provide them. Atomic operations like store and load seem to work fine, but it is weird that the fetch_and_... types are missing and does not seem to be documented anywhere

Error compiling some libraries with toolchain

Hello.

I am currently trying to use the library x25519-dalek for a project that needs to run on a ESP32. This means that we have no operating system and no STD. But the library should be in the category "No standard library" which should be fine for me in this case.

I am using this build chain, however it decides to give me an error.

But when attempting to build it I recieve the following error:

error: linking with `ldproxy` failed: exit status: 1
...
  = note: Running ldproxy
          Error: Linker /home/carl/.espressif/tools/xtensa-esp32-elf-clang/esp-13.0.0-20211203-x86_64-unknown-linux-gnu/bin/xtensa-esp32-elf-gcc failed: exit status: 1
          STDERR OUTPUT:
          /home/carl/.espressif/tools/xtensa-esp32-elf-clang/esp-13.0.0-20211203-x86_64-unknown-linux-gnu/bin/../lib/gcc/xtensa-esp32-elf/8.4.0/../../../../xtensa-esp32-elf/bin/ld: /home/carl/Documents/git/github/esp-rs/esp32-build/target/xtensa-esp32-espidf/debug/deps/libclear_on_drop-7f6bb154f7984c2b.rlib: error adding symbols: file format not recognized
          collect2: error: ld returned 1 exit status

full log here

And the project I am running and failing the build is this - The following line is what triggers this error

Hope this is something you can help me with.

Export path to clang's bin dir doesn't exist anymore with llvm 14

If you investigate the extracted LLVM dirs in .espressif/tools, you'll notice that LLVM 14 doesn't have a bin/ dir anymore.

cd ~/.espressif/tools
❯ ls xtensa-esp32-elf-clang/esp-13.0.0-20211203-x86_64-unknown-linux-gnu 
bin/  include/  lib/  libexec/  share/  xtensa-esp32-elf/
~/.espressif/tools 
❯ ls xtensa-esp32-elf-clang/esp-14.0.0-20220415-x86_64-unknown-linux-gnu/lib 
clang/  libclang.so@  libclang.so.13@  libclang.so.14.0.0*

As we can see, what was once the LLVM dir is now merely the contents of the former lib/ dir. However, the path to the now non-existent bin/ is still being exported.

Not sure what the right way to fix this is. Stop exporting the PATH to clang's bin? Download a different LLVM release?

Allow `--build-target all`

Allow parameter all for -b|--build-target argument to install both nightly and esp toolchain and, if some version of -s|--esp-idf-version is specified, install it for all boards.

riscv32imc-unknown-none-elf is not recognized by +esp toolchain

cd esp32c3-hal/examples/empty
cargo +esp-1.56.0.1 build
error[E0463]: can't find crate for `core`
  |
  = note: the `riscv32imc-unknown-none-elf` target may not be installed

While classical night works:

cargo build
Finished dev [unoptimized + debuginfo] target(s) in 10.94s

I would expect, that our toolchain is able to process the same build.
Adding the target to our toolchain does not work:

rustup target add riscv32imc-unknown-none-elf --toolchain +esp-1.56.0.1
error: toolchain '+esp-1.56.0.1' does not support components: +esp-1.56.0.1 is a custom toolchain

It seems that we need to turn on component support.

Cargo binary for macOS assumes OpenSSL is installed via Homebrew

When following the instructions to install the toolchain on macOS, the cargo that gets installed links to OpenSSL via the openssl-sys crate and has library paths that assume OpenSSL was installed via Homebrew.

This leads to the following error if OpenSSL is installed by, for example, MacPorts.

$ cargo +esp
dyld: Library not loaded: /usr/local/opt/[email protected]/lib/libssl.1.1.dylib
  Referenced from: /Users/steve/.rustup/toolchains/esp/bin/cargo
  Reason: image not found
Abort trap: 6

This can be fixed using install_name_tool(1).

$ install_name_tool -change /usr/local/opt/[email protected]/lib/libssl.1.1.dylib /opt/local/lib/libssl.3.dylib \
                    -change /usr/local/opt/[email protected]/lib/libcrypto.1.1.dylib /opt/local/lib/libcrypto.3.dylib \
                    cargo

This allows cargo to run, but the libraries have different compatibility versions so I'm not sure any OpenSSL functions would actually work correctly or not.

Mention in docs that rustup installed through snap has different paths set and creates issues

Hey!
I'm new to rust and was on to trying to replace some of my esp32 coding on arduino IDE with rust. I tried following this guide, but ran into trouble that I now resolved by installing rustup not via snap, but manually. Apparently the snap version of rustup stores its data somewhere else and therefore the default paths do not match well with the defaults set here.

Maybe it's enough for the next person to stumble upon this issue. I did not work out the snap paths but installed it manually instead, making it work instantly.

Cheers and keep up the good work :).

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.