Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Build seems to be broken #2

Open
Eeems opened this issue Oct 29, 2023 · 4 comments
Open

Build seems to be broken #2

Eeems opened this issue Oct 29, 2023 · 4 comments

Comments

@Eeems
Copy link

Eeems commented Oct 29, 2023

toltec-dev/toltec#748

@bkirwi
Copy link
Owner

bkirwi commented Jan 6, 2024

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 with toltecmk.
  • 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.

@Eeems
Copy link
Author

Eeems commented Jan 6, 2024

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 with toltecmk.
  • 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?

@bkirwi
Copy link
Owner

bkirwi commented Jan 8, 2024

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.

@Eeems
Copy link
Author

Eeems commented Jan 8, 2024

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: toltec-dev/toolchain#20

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants