| Summary: | Document build dependencies | ||
|---|---|---|---|
| Product: | buildroot | Reporter: | Jan-Benedict Glaw <jbglaw> |
| Component: | Other | Assignee: | unassigned |
| Status: | RESOLVED MOVED | ||
| Severity: | normal | CC: | buildroot, yann.morin.1998 |
| Priority: | P5 | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Host: | Target: | ||
| Build: | |||
|
Description
Jan-Benedict Glaw
2023-03-14 20:08:39 UTC
Thanks for the reporting the issue. However, the correct fix is not to add libssl-dev as a dependency of Buildroot. Instead if U-Boot needs OpenSSL on the host, the Buildroot option BR2_TARGET_UBOOT_NEEDS_OPENSSL should be enabled. Could you try adding BR2_TARGET_UBOOT_NEEDS_OPENSSL=y in the problematic defconfigs? This should address your problem. We normally also have CI to test all our defconfigs within a clean container, but our pipelines are so long that Gitlab CI is regularly aborting them in the middle, making said CI pretty useless unfortunately :-/ Once the current round of builds (about 2300 jobs, takes a few days) is done, I'll happily test adding BR2_TARGET_UBOOT_NEEDS_OPENSSL=y to those configs and re-run them with a container that doesn't have libssl-dev installed. (As I realized this possible dependency, I added libssl-dev to the container, not thinking about adding the dep'cy to the config. So this run won't catch other configurations in need of BR2_TARGET_UBOOT_NEEDS_OPENSSL=y, but the next round will catch that.) As for CI builds, I cannot do daily builds (scheduling isn't an issue, but I don't have the computation power), but if it's going to be helpful, I'll keep buildroot builds every now and then. Will probably come out as one (full) build every three to four weeks. Hi Thomas! As I read through your comment again, you're running your CI builds on the Gitlab.com platform? Or on a self-hosted system? If it's self-hosted, you can easily change configuration to allow for longer running jobs. All CI testing I do is strictly non-parallel (to allow to diff log files), so it takes its time (eg. right now, a build for qemu_aarch64_sbsa_defconfig is already running for 7h 50m right now), though I'm not using Gitlab, but Laminar (self-hosted in my basement.) On my hardware, I guess (don't have numbers yet) an average buildroot build will take 4.5h, times 280 builds, resulting in some 75k build minutes just for one complete run. That's already quite more than Gitlab.com's "Ultimate" plan. :/ While I currently pay for electricity myself, let me know if I'd do helpful work in that area in the long run. As I do Buildroot builds only as a side project (my main target for http://toolchain.lug-owl.de/ is to keep GCC running for VAX, keep NetBSD for VAX alive), even running a small RasPi cluster as build nodes would probably beneficial. It wouldn't be _fast_ either, but it could properly build all configurations and start from the beginning once a complete round is finished. NB: A rough estimate shows that tonight a full round of all Buildroot sample configurations should be finished. (Some were built with a Docker container containing libssl-dev, I removed that again, so I might miss a few configurations that were in need of BR2_TARGET_UBOOT_NEEDS_OPENSSL=y) Alas... Tomorrow, I'll be able to give a summary and/or open tickets for configurations that failed to build. Right now, i have about 12 failed builds (out of around 210 that were scheduled and are done.) The beaglebone_defconfig configuration also needs SSL. ...and nitrogen6x_defconfig and nitrogen7_defconfig as well. Thank you for your report.
The issue tracker for the Buildroot project has been moved to
the Gitlab.com issue tracker:
https://gitlab.com/buildroot.org/buildroot/-/issues
We are taking this opportunity to close old issues in this old
tracker. If you believe your issue is still relevant, please
open one in the new issue tracker.
Thank you!
|