search

esp-rs / esp-idf-template

A "Hello, world!" template of a Rust binary crate for the ESP-IDF framework.
414 stars 50 forks source link

Compile binaries to avoid GLIBC missmatch error #176

Closed yagop closed 9 months ago

yagop commented 9 months ago

Compile espup, ldproxy espflash and esp-web-flash-server to avoid GLIBC missmatch error.

Seems some binaries are published with newer GLIBC version which bullseye doesn't support.

Is cargo-espflash needed?

Vollbrecht commented 9 months ago

if that is the problem we need to fix that in the pre-compiled binary's. Building them from scratch just explodes the container size and its layers for no good reason for the end user. If you love your disk you don't want to do this

yagop commented 9 months ago

if that is the problem we need to fix that in the pre-compiled binary's. Building them from scratch just explodes the container size and its layers for no good reason for the end user. If you love your disk you don't want to do this

If size and layers is a problem, can use multi staged Docker builds.

I personally prefer compiling all the stuff rather than download unsigned binaries from the web ...

SergioGasquez commented 9 months ago

I personally prefer compiling all the stuff rather than download unsigned binaries from the web ...

Why do you dislike unsigned binaries?

Also, having the version of every crate hard-coded is very inconvenient, as we would need to update them every release.

SergioGasquez commented 9 months ago

Just created https://github.com/esp-rs/esp-idf-template/pull/177 which solves the GLIBC error

yagop commented 9 months ago

Why do you dislike unsigned binaries?

They can be malware ...

Also, having the version of every crate hard-coded is very inconvenient, as we would need to update them every release.

Should be using version to avoid break compatibility and to do reproducible builds

Vollbrecht commented 9 months ago

If you are unsure about binary's that come from the official GH releases, you may want to look at other tools, as this devcontainer is not created for that use-case in mind.

The goal's of this devcontainer is not to create a reproducible tool-chain in the first place( it can be that but only if other goals don't suffer to much here) , rather it is more optimized for separation of concerns and trying to be lightweight overall, and get a user a working tool-chain without much hassle, though the 2nd point is still a thing that needs more improvement.

Some people are trying nix packages for immutable build systems, that may be an better alternative for you. Though this is i think a pretty bumpy road that is not just a thing everybody will be able to do.

Also, having the version of every crate hard-coded is very inconvenient, as we would need to update them every release.

Should be using version to avoid break compatibility and to do reproducible builds

This is the same for the rust compiler version you are installing here. We are working on fixed prebuild containers with locked version, to specific xtensa and nightly versions and in some form they already exist on dockerhub but they also need some more improvement. If you need that in your project i suggest not using this current devcontainer.

SergioGasquez commented 9 months ago

They can be malware ...

We used to sign espup for Windows, but we stopped doing that, the binaries are usually built in the CI of the repo, so you can see what and how is producing them.

Should be using version to avoid break compatibility and to do reproducible builds

I agree with what @Vollbrecht mentioned, you can always modify your generated template Dockerfile

SergioGasquez commented 9 months ago

I will close this issue in favor of #177