Compile binaries to avoid GLIBC missmatch error

[yagop]

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]

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

[SergioGasquez]

Probably the good solution here would be to update the Debian variant to bookworm or bookworm-slim . This version should have compatible GLIBC version.

Edit: Note to myself, we should also update esp-template with this.

[yagop]

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]

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]

Just created #177 which solves the GLIBC error

[yagop]

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]

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]

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]

I will close this issue in favor of #177