Open Eeems opened 10 months ago
I've looked into this over the holiday. Some rough notes:
toltec
on my machine. (Using the standard RM toolchain etc.) However it's quite straightforward to reproduce the issue with toltecmk
.libclang
packages with slightly different libraries.tflite
library in rust to be a pain, and it's barely maintained. ONNX is an alternative ML runtime format that is better supported in Rust and appears to have comparable performance. I'd like to try migrating over, though that may take some time.I've looked into this over the holiday. Some rough notes:
- The build works outside of
toltec
on my machine. (Using the standard RM toolchain etc.) However it's quite straightforward to reproduce the issue withtoltecmk
.- Versions of this package that previously built successfully under toltec will now fail. I think -- but am not certain -- that the difference is in the build environment -- toltec pulling in more recent versions of the Debian
libclang
packages with slightly different libraries.- Upgrading relevant libraries on the Rust side (bindgen etc.) does not seem to help.
- Generally speaking I've found working with the
tflite
library in rust to be a pain, and it's barely maintained. ONNX is an alternative ML runtime format that is better supported in Rust and appears to have comparable performance. I'd like to try migrating over, though that may take some time.
The image version used should not have changed since this was initially built and working, but perhaps something did change. Have you tried using an older image tag?
The change is not the image itself, but the packages it pulls in. folly
requires various build dependencies:
makedepends=(build:librust-clang-sys-dev build:libclang-dev build:libc6 build:libc6-dev build:clang)
When I build via toltecmk
, I get, among other things:
Setting up clang (1:16.0-57) ...
And version 16 of clang was not released until march this year. Which makes some sense: I don't think toltec is doing anything to pin all upstream packages or whatever. But it does make the build nonreproducible.
I'm tempted to propose that clang etc. be baked into the rust image, since they're common build-time dependencies. But that seems like a bit of a hack and I'm not sure I like it yet.
The change is not the image itself, but the packages it pulls in.
folly
requires various build dependencies:makedepends=(build:librust-clang-sys-dev build:libclang-dev build:libc6 build:libc6-dev build:clang)
When I build via
toltecmk
, I get, among other things:Setting up clang (1:16.0-57) ...
And version 16 of clang was not released until march this year. Which makes some sense: I don't think toltec is doing anything to pin all upstream packages or whatever. But it does make the build nonreproducible.
I'm tempted to propose that clang etc. be baked into the rust image, since they're common build-time dependencies. But that seems like a bit of a hack and I'm not sure I like it yet.
Ah, fair point. Yeah, creating pinned versions of the debian package repos is out of scope for us right now. It's also not often that we expect a compiler to break builds. I do think it would be worth baking clang into the base toolchain image, as it's a fairly standard build tool. That would be done as a v3.2 tag in my opinion.
I've documented how to modify the toolchain images here: https://github.com/toltec-dev/toolchain/issues/20
https://github.com/toltec-dev/toltec/issues/748