Fails to build freshly cloned on NixOS #64
Comments
|
Hi! Do you have |
|
Thanks! It seems I didn't have it on that shell at the time. However, another error emerges: |
|
Have you tried doing |
|
I have. This is my flake.nix which defines my entire dev environment of top of my system (although the system exposes very little): On top of which I've also ran (for the Nth time, some of these): and I get the same error. I have not sourced anything else. Should I be sourcing something? |
|
Hi! I've never used nix, I will give it a try with the docker image
I see that the flake its using an overlay (not sure of how this work exactly) but I think its using esp-idf v4.4.1 by default, while the template uses I would recommend doing two different tests:
|
|
Overlays allow modifying the list of available packages, I'm only installing I actually once tried using the I just tried using espup, and running Anyway, I've built a reproducer for my last error. The gcc compiler for this target apparently wants to use fancy sandboxing techniques on its own which are filtered by Docker's seccomp list, so you'll have to run the image interactively with these flags https://gist.github.com/mixedCase/58c6690caf25bf2b48f7b675fe9c0c7c You'll have to download those 4 files into a folder, build the image and run it with the flags I mentioned. Like this for example: You can add more packages into your shell by either adding them to the flake.nix and rebuilding the image or interactively inside the container by running Thanks for all your help so far! |
Somehow,
Bindgen (i.e. libclang) uses the wrong headers here. It should definitely not use the system glibc headers. This is likely also related to the previous problem, even though the esp-idf build succeeds. You could try to remove the package that provides the glibc headers (maybe This is just my two cents, without digging deeper, hope it helps a little bit. |
|
@N3xed Thanks for the response. Could you tell me how is clang being invoked to find these headers? I am not very familiar with C build systems. I do know that Nix's compiler environment is very strict about how things are done when rolling your own build system outside of Nix, so it might just be a thing of being extra specific rather than assuming the system has something somewhere because it's likely that assumption is broken on NixOS. Same deal about using shipped binaries that assume FHS for linked libraries, if |
|
Well, of course right after I ask another question I manage to work around the issue: I removed clang and gcc both from my system and from the flake, and it's now compiling both natively and cross compiling to riscv32imc-esp-espidf just fine. This is the flake with which I was able to cross-compile: However: it's definitely still a problem that the system clang interferes with the build script. How is the script deciding what to call? Is it perhaps relying on PATH and adding its tools at the end of it? |
If you have |
|
@SergioGasquez Ah, good to know! Thanks. Is there a reason why system clang is preferred over the vendored version? IIUC ESP-IDF is handled the other way around, where one has to configure via env a lib path to choose anything other than the "known-good" version. |
Not sure but feel free to ask in espressif/llvm-project |
Well, basically esp-idf's infrastructure doesn't include clang as it doesn't need it. We only need libclang for bindgen to generate the Rust bindings to the esp-idf C headers. But since upstream llvm/clang doesn't support xtensa yet, a custom llvm/clang installation is needed. (Note that if you were to compile for the esp32c3 that wouldn't be a problem, since llvm supports risc-V.) We use |
|
Understandable. Thanks for the help, I'm closing the issue and leaving here the final working flake.nix (with some extra dependencies I've had to add to also build Slint for x86_64 at least) in case anyone else's coming here from a search engine: |
Thanks for sharing it! In case you didn't know, here is a slint example. Is your project open by any chance? |
|
@SergioGasquez Thanks for the link! I'd only been looking at the slint-mcu-rust-template and associated internal crate so far, so anything extra is welcome. The project is not open at least for the moment, but if no one beats me to the punch and I can get everything going I'll hopefully get some time to share a slightly opinionated ESP32-C3 template based on the MPI3501 LCD. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Build logs:
The text was updated successfully, but these errors were encountered: