Difference between revisions of "Buildroot"

From eLinux.org
Jump to: navigation, search
(Core Buildroot infrastructure: ARCH_HAS_MMU)
(Add 2024 Developer days, move past events)
 
(140 intermediate revisions by 22 users not shown)
Line 3: Line 3:
 
== Important links ==
 
== Important links ==
  
* [http://www.buildroot.org Buildroot main page]
+
* [https://www.buildroot.org Buildroot main page]
* [http://bugs.uclibc.org Bug tracker]
+
* [https://bugs.uclibc.org Bug tracker]
 
* [http://autobuild.buildroot.org Autobuilders results]
 
* [http://autobuild.buildroot.org Autobuilders results]
* [http://patchwork.ozlabs.org/project/buildroot/list/ Project patchwork]
+
* [https://patchwork.ozlabs.org/project/buildroot/list/ Project patchwork]
 +
* [[Buildroot:ReproducibleBuilds | The reproducible builds work]]
 +
* [[Buildroot:Top_Level_Parallel_Build | The top-level parallel build work]]
 +
* [[Buildroot:Security_Vulnerability_Management | Security Vulnerability Management]]
 +
* [[Buildroot:Language_package_managers_and_dependencies | Language package managers and downloading dependencies (go mod, cargo, php compose)]]
  
 
== Developer days ==
 
== Developer days ==
  
 
Upcoming:
 
Upcoming:
* [[Buildroot:DeveloperDaysELCE2014 | Buildroot Developer Days]], October 2014, Düsseldorf, Germany, before or after ELC-E.
+
* [[Buildroot:DeveloperDaysFOSDEM2024 | Buildroot Developer Days]], 5-7 February 2024, Brussels, Belgium, after [https://fosdem.org/2024/ FOSDEM]
  
 
Past:
 
Past:
 +
* [[Buildroot:DeveloperDaysFOSDEM2023 | Buildroot Developer Days]], 6-8 February 2023, Brussels, Belgium, after [https://fosdem.org/2023/ FOSDEM]
 +
* [[Buildroot:DeveloperDaysELCE2022 | Buildroot Developer Days]], 17-18 September 2022, Dublin, Ireland, after [https://events.linuxfoundation.org/open-source-summit-europe/about/embedded-linux-conference/ ELCE]
 +
* [[Buildroot:VirtualDeveloperDaysSummer2020 | Virtual Buildroot Developer Days]], July 27, August 28, August 29, 2020
 +
* [[Buildroot:DeveloperDaysFOSDEM2020 | Buildroot Developer Days]], 3-5 February 2020, Brussels, Belgium, after [http://fosdem.org FOSDEM]
 +
* [[Buildroot:DeveloperDaysELCE2019 | Buildroot Developer Days]], 25-27 October 2019, Lyon, France, before [https://events19.linuxfoundation.org/events/embedded-linux-conference-europe-2019/ ELCE]
 +
* [[Buildroot:DeveloperDaysFOSDEM2019 | Buildroot Developer Days]], 4-6 February 2019, Brussels, Belgium, after [http://fosdem.org FOSDEM]
 +
* [[Buildroot:DeveloperDaysELCE2018 | Buildroot Developer Days]], 20-21 October 2018, Edinburgh, UK, before [https://events.linuxfoundation.org/events/elc-openiot-europe-2018/ ELCE]
 +
* [[Buildroot:DeveloperDaysFOSDEM2018 | Buildroot Developer Days]], 5-6 February 2018, Brussels, Belgium, after [http://fosdem.org FOSDEM]
 +
* [[Buildroot:DeveloperDaysELCE2017 | Buildroot Developer Days]], 21-22 October 2017, Prague, Czech Republic, before [http://events.linuxfoundation.org/events/embedded-linux-conference-europe ELCE].
 +
* [[Buildroot:DeveloperDaysFOSDEM2017 | Buildroot Developer Days]], 6-7 February 2017, Brussels, Belgium, after [http://fosdem.org FOSDEM]
 +
* [[Buildroot:DeveloperDaysELCE2016 | Buildroot Developer Days]], 14-16 October 2016, Berlin, Germany, after [http://events.linuxfoundation.org/events/embedded-linux-conference-europe ELCE].
 +
* [[Buildroot:DeveloperDaysFOSDEM2016 | Buildroot Developer Days]], 1-2 February 2016, Brussels, Belgium, after [http://fosdem.org FOSDEM]
 +
* [[Buildroot:DeveloperDaysELCE2015 | Buildroot Developer Days]], 3-4 October 2015, Dublin, Ireland, before ELC-E ([http://elinux.org/index.php?title=Buildroot:DeveloperDaysELCE2015#Report report]).
 +
* [[Buildroot:DeveloperDaysFOSDEM2015 | Buildroot Developer Days]], 2-3 February 2015, Brussels, Belgium, after FOSDEM.
 +
* [[Buildroot:DeveloperDaysELCE2014 | Buildroot Developer Days]], 11-12 October 2014, Düsseldorf, Germany, before ELC-E.
 
* [[Buildroot:DeveloperDaysFOSDEM2014 | Buildroot Developer Days]], 3-4 February 2014, Brussels, Belgium, after FOSDEM.
 
* [[Buildroot:DeveloperDaysFOSDEM2014 | Buildroot Developer Days]], 3-4 February 2014, Brussels, Belgium, after FOSDEM.
 
* [[Buildroot:DeveloperDaysELCE2013 | Buildroot Developer Days]], 26-27 October 2013, Edinburgh UK, after ELC-E.
 
* [[Buildroot:DeveloperDaysELCE2013 | Buildroot Developer Days]], 26-27 October 2013, Edinburgh UK, after ELC-E.
Line 20: Line 39:
 
* Buildroot Developer Days, 3 February 2012, Brussels Belgium, before FOSDEM ([http://lists.busybox.net/pipermail/buildroot/2012-February/050371.html report])
 
* Buildroot Developer Days, 3 February 2012, Brussels Belgium, before FOSDEM ([http://lists.busybox.net/pipermail/buildroot/2012-February/050371.html report])
 
* Buildroot Developer Days, 29 October 2011, Prague, Czech Republic, after ELCE ([http://lists.busybox.net/pipermail/buildroot/2011-November/047229.html report])
 
* Buildroot Developer Days, 29 October 2011, Prague, Czech Republic, after ELCE ([http://lists.busybox.net/pipermail/buildroot/2011-November/047229.html report])
 +
 +
== Talks ==
 +
 +
This section gathers the list of talks given about Buildroot, as well as the slides and video when available.
 +
 +
Past:
 +
* [https://elciotna18.sched.com/event/E4qS/buildroot-whats-new-thomas-petazzoni-bootlin-formerly-free-electrons Buildroot: What's New?], Thomas Petazzoni, Embedded Linux Conference, 12-14 March, Portland, Oregon. [https://bootlin.com/pub/conferences/2018/elc/petazzoni-buildroot-whats-new/petazzoni-buildroot-whats-new.pdf Slides], [https://www.youtube.com/watch?v=D6zO4nMX9KY Video].
 +
* [https://osseu17.sched.com/event/ByYU/buildroot-whats-new-thomas-petazzoni-free-electrons Buildroot: What's New?], Thomas Petazzoni, Embedded Linux Conference Europe, 23-25 October, Prague, Czech Republic. [https://elinux.org/images/b/bb/Elce2017-petazzoni-buildroot-whats-new.pdf Slides], [https://youtu.be/839WOdYPYuE Video].
 +
* [https://osseu17.sched.com/event/ByYX/buildroot-making-embedded-linux-easy-a-real-life-example-yann-morin-orange Buildroot: Making Embedded Linux Easy? A Real-Life Example], Yann E. MORIN, Embedded Linux Conference Europe, 23-25 October, Prague, Czech Republic. [https://elinux.org/images/8/8e/2017-10-24_-_ELCE-Buildroot.pdf Slides], [https://youtu.be/SN2hYO2rYtk Video].
 +
* [http://sched.co/3y4O Tutorial: Learning the Basics of Buildroot], Thomas Petazzoni, Embedded Linux Conference Europe, October 5 - 7, 2015, Dublin, Ireland. [https://elinux.org/images/1/1e/Petazzoni-buildroot-tutorial.pdf Slides], [https://www.youtube.com/watch?v=1PfthHCfudY Video].
 +
* "Buildroot: a deep dive into the core", Thomas Petazzoni, Embedded Linux Conference Europe, 13-15 October 2014, Düsseldorf, Germany. [http://events.linuxfoundation.org/sites/events/files/slides/petazzoni-dive-into-buildroot-core.pdf Slides].
 +
* [http://elcabsna2014.sched.org/event/ce9732e662300bace37607a6adacf82b Buildroot: what's new], Thomas Petazzoni, Embedded Linux Conference, 1 May 2014, San Jose, United States. [http://elinux.org/images/1/1d/Petazzoni-buildroot-whats-new.pdf Slides], [http://free-electrons.com/pub/video/2014/elc/elc-2014-thomas-petazzoni-buildroot.webm HD video], [http://free-electrons.com/pub/video/2014/elc/elc-2014-thomas-petazzoni-buildroot-450p.webm Low-res video], [http://events.linuxfoundation.org/sites/events/files/Buildroot%20What%27s%20New%20-%20Thomas%20Petazzoni-%20Free%20Electrons.mp3 Audio only]
 +
* "Buildroot: what is new", Peter Korsgaard, Embedded Linux Conference Europe, 25 October 2013, Edinburgh, UK. [http://elinux.org/images/2/23/Buildroot-whats-new-elce2013.pdf Slides], [https://www.youtube.com/watch?v=0G_yJ50RA3I Video].
  
 
==List of forks==
 
==List of forks==
  
* [https://github.com/nezticle/RaspberryPi-BuildRoot]. A Rasberry-Pi related fork.
+
* [https://github.com/skiffos/skiffos SkiffOS] is a modular config layering system for Buildroot with support for 50+ targets.
* [https://github.com/albertd/buildroot-rpi]. Another RPi related fork, with a lot of focus on Qt5 and GStreamer.
+
* [https://batocera.org/ Batocera.linux] is an open-source and completely free retro-gaming distribution.
 +
* [https://github.com/home-assistant/operating-system Home Assistant Operating System]. Home Assistant Operating System (formerly HassOS) is an operating system optimized for hosting Home Assistant and its Add-ons.
 +
* [https://github.com/openil/openil OpenIL]. OpenIL is an open source project based on Buildroot and designed for embedded industrial solution.
 +
* [https://github.com/nezticle/RaspberryPi-BuildRoot Bsquask SDK]. A Rasberry-Pi related fork.
 +
* [https://github.com/albertd/buildroot-rpi buildroot-rpi]. Another RPi related fork, with a lot of focus on Qt5 and GStreamer (appears to be defunct).
 +
* [https://github.com/Openwide-Ingenierie/buildroot-submodule Buildroot Submodule]. Not a fork, but a convenience layer on top of buildroot.
 +
* [http://ymorin.is-a-geek.org/git/buildroot.config/ Experimental 'shell' around Buildroot]. Another wrapper around Buildroot, to help manage projects.
  
 
==Todo list==
 
==Todo list==
Line 30: Line 68:
 
This is a list of improvements that we would like to see in buildroot.  Feel free to add suggestions here.  If you're working on one of these items, put your name and the date behind it, to avoid duplicate work.
 
This is a list of improvements that we would like to see in buildroot.  Feel free to add suggestions here.  If you're working on one of these items, put your name and the date behind it, to avoid duplicate work.
  
There are a number of patches that have been determined to be useful but for various reasons nobody currently has time to review or test them. Anybody, especially a person new to buildroot, is welcome to adopt these patches and resubmit them to the mailing list. These patches can be viewed by looking at the following link - http://patchwork.ozlabs.org/project/buildroot/list/?state=1&delegate=7151
+
There are a number of patches that have been determined to be useful but for various reasons nobody currently has time to review or test them. Anybody, especially a person new to buildroot, is welcome to adopt these patches and resubmit them to the mailing list.
 +
 
 +
=== Perpetual work ===
 +
 
 +
Some jobs are never finished. When you have a bit of uninterrupted time you would like to spend on Buildroot, you can pick one of these things.
 +
 
 +
==== Autobuild failures ====
 +
 
 +
The [http://autobuild.buildroot.net/?status=NOK autobuild failures] are random configurations for which the build fails. This is what we want to fix. A summary of failures is [https://lore.kernel.org/buildroot/?q=autobuild.buildroot.net+Daily+results sent daily to the mailing list], this gives a good summary of the most frequently failing packages.
 +
 
 +
* Go to the failing output ("end log" link) and see if it's an error message that you can make sense of. Often you can't, then just skip it and look for something else.
 +
* Check on [https://patchwork.ozlabs.org/project/buildroot/ patchwork] if a fix was already posted. Also check in recent commit history if a fix was already committed. Also ask [https://buildroot.org/support.html on IRC] if someone is working on it.
 +
* Reproduce the issue with the [https://git.buildroot.org/buildroot-test/tree/utils/br-reproduce-build br-reproduce-build script]. However, it is often easier to first attempt to reproduce it by simply downloading the defconfig as <code>.config</code>, run <code>make olddefconfig</code>, then <code>make <the package that fails></code>. Not all issues can be reproduced this way however! Also, if the failing configuration was using a Buildroot toolchain rather than an external toolchain, it can be worth to first try to reproduce with an external toolchain (which reduces the build time by quite a lot).
 +
* Produce a fix. Here are some hints.
 +
** Perhaps the package simply doesn't support that configuration (target architecture, libc type, static build, threads, GCC version) and a dependency has to be added in Config.in.
 +
** Sometimes a fix was already found by someone else and sent upstream, so check its bugs list, pull requests and recent commits. Also check if OpenEmbedded has a fix already.
 +
** Sometimes a similar issue was recently fixed for another package, so you can <code>git log --grep '<some part of the error message>'</code>.
 +
* Test the fix with the actual configuration (so no switching to external toolchain any more). Do a full clean build.
 +
* Check your changes with the <code>utils/check-package</code> script.
 +
* Post your fix according to [https://buildroot.org/downloads/manual/manual.html#submitting-patches the contribution guidelines] in the manual.
 +
 
 +
See [https://git.buildroot.org/buildroot/commit/?h=2022.05.x&id=2cbcdbf0add46da55020eb56b5e4b974b44e958b this commit] for an example of what the commit message should look like. Important is to have:
 +
* the compilation error;
 +
* the Fixes: line;
 +
* your Signed-off-by.
 +
 
 +
==== Update CVE exceptions ====
 +
 
 +
Buildroot keeps track of which CVEs apply to each package, based on a CPE ID. However, many CVEs don't actually apply. In particular very old CVEs are likely not to be applicable to the version currently shipped in Buildroot.
 +
 
 +
* Look at [http://autobuild.buildroot.net/stats/master.html the package statistics]. Sort by "CVEs". Look for a package with old CVEs.
 +
* For each CVE, check if it really applies.
 +
* If not, update the package's <code>FOO_IGNORE_CVES</code> with the CVE to ignore. Commit with a commit message that explains in detail why the CVE can be ignored. [https://gitlab.com/buildroot.org/buildroot/-/commit/8ae9156d8b730689484927fba2ec2fa6c1dc0433 Example commit message].
 +
* If the CVE really applies, check if there is an upstream patch fixing it.
 +
* Check your changes with the <code>utils/check-package</code> script.
 +
* Post your fix according to [https://buildroot.org/downloads/manual/manual.html#submitting-patches the contribution guidelines] in the manual.
  
 
=== Packages ===
 
=== Packages ===
Line 36: Line 109:
 
'''Note: if you start working on any of these packages, please edit this section to indicate it. If the package is proposed in a bug report, please also update the bug report. Sending a mail to the mailing list also never hurts, you never know that someone else started working on it without following this guideline.'''
 
'''Note: if you start working on any of these packages, please edit this section to indicate it. If the package is proposed in a bug report, please also update the bug report. Sending a mail to the mailing list also never hurts, you never know that someone else started working on it without following this guideline.'''
  
* Create a package for the x86-video-fbturbo driver. See https://github.com/ssvb/xf86-video-fbturbo.
+
==== Important ====
* Create a package for the Qt5 Cinematic Experience demonstration. See http://quitcoding.com/?page=work.
+
 
 +
* Instead of building the Go compiler, add support for using a pre-compiled Go compiler, like we do for Rust
 +
* Instead of building host-nodejs, add support for using a pre-compiled NodeJS for the host
 +
* Improve the imx-gpu-viv package to not install everything. See https://lore.kernel.org/buildroot/20210805233615.4e69d63d@windsurf/T/#u
 +
 
 +
==== Nice to have ====
 +
 
 +
* Extend support/scripts/setlocalversion to include the git/hg version(s) of BR2_EXTERNAL.
 
* Create a package for the Qt5 demo/benchmark application at https://github.com/prabindh/xgxperf.
 
* Create a package for the Qt5 demo/benchmark application at https://github.com/prabindh/xgxperf.
* Enable MIPS32 and MIPS64 support in Valgrind
 
* Switch the procps package to use http://sourceforge.net/projects/procps-ng/ which is the new active upstream.
 
* Remove the texinfo package, no longer needed after ct-ng backend removal
 
* Create a package for WebkitNix. See https://github.com/WebKitNix/webkitnix.
 
* Allow a second Barebox build, to build the MLO/SPL. See http://patchwork.ozlabs.org/patch/207942/ and http://patchwork.ozlabs.org/patch/207943/. The proposed design is to have boot/barebox/ containing the common stuff, and then two separate packages boot/barebox-first/ and boot/barebox-second/ (names to be chosen). There is only one version selection, but each package allows to define the configuration to be used. Design should be a little bit like package/gcc, where we have multiple gcc builds, but share a lot of common definitions between the packages.
 
 
* Packages proposed in bug reports (often with patch)
 
* Packages proposed in bug reports (often with patch)
 
** openvz https://bugs.busybox.net/show_bug.cgi?id=405
 
** openvz https://bugs.busybox.net/show_bug.cgi?id=405
** rdiff-backup https://bugs.busybox.net/show_bug.cgi?id=1309
+
** rdiff-backup https://bugs.busybox.net/show_bug.cgi?id=1309 [Shaym Saini <mayhs11saini@gmail.com> is working on this]
** nginx https://bugs.busybox.net/show_bug.cgi?id=3427
 
** libav https://bugs.busybox.net/show_bug.cgi?id=3655 (Spenser Gilliland is working on this)
 
** open-vm-tools https://bugs.busybox.net/show_bug.cgi?id=3991
 
** ratpoison https://bugs.busybox.net/show_bug.cgi?id=325
 
 
** wxWidgets https://bugs.busybox.net/show_bug.cgi?id=261
 
** wxWidgets https://bugs.busybox.net/show_bug.cgi?id=261
* Create a package for Gtk3
+
* Create a package for UnixBench benchmark suite at https://github.com/kdlucas/byte-unixbench.
* Update the webkitgtk package to a more recent version
+
* uwsgi => Adam Duskett pending patch series: https://patchwork.ozlabs.org/project/buildroot/list/?series=144709&state=%2A&archive=both
* Cleanup the libcgi package, by using https://github.com/rafaelsteil/libcgi as an upstream.
 
* Update the at package to use the upstream at http://anonscm.debian.org/gitweb/?p=collab-maint/at.git;a=summary. It would allow to remove at least two patches from our patch stack. And also, submit the remaining of our patches to the new maintainers.
 
  
=== Documentation ===
+
=== Toolchain ===
  
* [[Buildroot how to contribute | Document how to contribute]] (patches to list instead of bugzilla, SOB, formatting rules, acked-by and tested-by, how often to repost, what to expect, CC's, ...) [[Buildroot how to contribute | basic guide]]
+
* Add the support for the x86-64 x32 capable toolchain. See http://patchwork.ozlabs.org/patch/561904/
* Document how a package patch should be formatted (Comment, SOB, file naming rules, ...) + send upstream + CC sendpatches
+
* Add the support for the Aarch64 ilp32 capable toolchain (for now the gcc/binutils/glibc upstream support is not ready yet). See http://lists.busybox.net/pipermail/buildroot/2015-August/137356.html, http://patchwork.ozlabs.org/patch/506803/, http://patchwork.ozlabs.org/patch/506800/, http://patchwork.ozlabs.org/patch/506801/
* In documentation, explain how to report a bug
 
* Upgrade the buildroot website (ThomasP has a mockup of a new website)
 
  
=== Build/release infrastructure ===
+
=== Documentation ===
  
* Peter sets up a planet on whatever server and links to it from buildroot website
+
* Convert the documentation + the generation workflow from current asciidoc to either markdown or ReStructuredText (people are nowadays more used to that syntax, and they are formatted directly when viewed in gitlab/github).
 +
* [[Buildroot how to contribute | Document how to contribute]] (how often to repost, what to expect, ...) [[Buildroot how to contribute | basic guide]]
 +
* Document that package patches should be sent upstream
  
 
=== Core Buildroot infrastructure ===
 
=== Core Buildroot infrastructure ===
  
* ldconfig handling is broken, see http://patchwork.ozlabs.org/patch/255486/
+
* Cargo and Go post-process handling for vendoring
 +
** Add support for tarball formats other than gz
  
* Locale handling is broken: it doesn't take into account the alias file when purging aliases. See [http://lists.busybox.net/pipermail/buildroot/2013-December/084724.html this mail from patchwork cleanup #3] and [http://patchwork.ozlabs.org/patch/188623/ this patch that also fixes a locale problem, but not everything]
+
* Cargo post-process handling for vendoring
 +
** Either replace "cargo install" by manual installation of files, or ensure that "cargo install" doesn't rebuild things. See https://lore.kernel.org/buildroot/20220106210000.397694-1-thomas.petazzoni@bootlin.com/T/#m2fe31f718c45675f7fb52d001e75cc0386db8aee
 +
** Use more environment variables when calling cargo, to avoid using a cargo configuration file. See https://lore.kernel.org/buildroot/20220106210000.397694-1-thomas.petazzoni@bootlin.com/T/#m8dc0e19638fc1f2c36cac7bba5de615a2a671dc1
  
* It would be nice to add a br-configure script in host/usr/bin for autotools-based packages. Run ...BUILDROOTSDK/usr/bin/br-configure --enable-foo --disable-bar, and the br-configure script would call the ./configure script in the current directory passing all the right options (--host, and all environment variables CC, LD, AS, AR and such).
+
* Investigate adding support for [https://github.com/icecc ICECC]. See also https://www.pengutronix.de/en/2018-09-13-fixing-icecc.html.
  
* Make the HOST-directory a relocatable SDK:
+
* Several improvements are possible in the download infrastructure (even after all the improvements that were already done):
** Make sure that all binaries and libraries built for the host are built with a rpath pointing to host/usr/lib. Normally, this should already be the case, but it's worth checking.
+
** Rename the downloaded files so they include the package name and version. Special care has to be taken for primary and secondary sites, and for extra downloads (including patches).
** Change the rpath value to $ORIGIN/../lib instead of the current absolute path $(O)/host/usr/lib.
+
** Split between FOO_SITE and FOO_SOURCE shouldn't be necessary. Or it could be made optional, i.e. make it possible to specify the full path in FOO_SOURCE.
** Modify the compiler wrapper program of external toolchains so that instead of using a fixed location for the compiler tools, it deduces their location in a relative manner from its current location.
 
** Modify/patch pkg-config so that instead of having a fixed location for the PKG_CONFIG_PATH and PKG_CONFIG_SYSROOT_DIR, those are deduced from the location of the pkg-config binary. This will allow a pkg-config binary that has been moved to still operate properly, without having to set any environment variable.
 
** Write a shell script, installed in host/usr/bin, which would mungle the libtool .la files, the qmake.conf file and the CMake toolchain file to set the correct path. This script reads a file (can be host/usr/share/buildroot/location) which contains the original location of the SDK. This allows the script to do the right modifications on all the libtool, qmake.conf and cmake files. Once this is done, the script changes the host/usr/share/buildroot/location file so that it contains the new location.
 
** Modify the external toolchain wrapper so that it bails out and warns the user if the directory it is executed in doesn't match the location of host/usr/share/buildroot/location. We haven't discussed how this could work with internal and crosstool-NG toolchains, though.
 
  
* Properly detect thread and TLS support in external toolchains, or make TLS knob driven by thread availability in the toolchain. See the discussion in http://patchwork.ozlabs.org/patch/288051/ as reference)
+
* Locale handling is broken: it doesn't take into account the alias file when purging aliases. See [http://lists.busybox.net/pipermail/buildroot/2013-December/084724.html this mail from patchwork cleanup #3] and [http://patchwork.ozlabs.org/patch/188623/ this patch that also fixes a locale problem, but not everything]. Tests for this are also required.
  
* Add intrumentation scripts to analyse package installed files:
+
* Add instrumentation scripts to analyse package installed files:
** identify what package installed what files, identify files overriden by a later package
 
 
** find libraries with wrong RPATH/RUNPATH tags
 
** find libraries with wrong RPATH/RUNPATH tags
 
** detect unused .so libs (eg. shared libs that are not DT_NEEDED by anything - note: only detect those libs, don't remove: can be used as plugin (dlopen), or used by an application built outside Buildroot)
 
** detect unused .so libs (eg. shared libs that are not DT_NEEDED by anything - note: only detect those libs, don't remove: can be used as plugin (dlopen), or used by an application built outside Buildroot)
  
* Make a split between BR2_USE_MMU and BR2_ARCH_HAS_MMU. This is triggered by patches http://patchwork.ozlabs.org/patch/272450/ and http://patchwork.ozlabs.org/patch/273066/. See the discussion on these patches for more details.
+
* A script that checks consistency of depends/select for packages. Maybe it can be integrated to the current check-package.
 +
 
 +
* [[Buildroot:SecurityHardening | Security Hardening]]
 +
 
 +
=== Testing infrastructure ===
 +
 
 +
* Fix run-tests to use a config file for download and output directories, can be overridden in the environment
 +
* Documentation on how to add a test, including naming convention
  
 
=== TODO items under discussion ===
 
=== TODO items under discussion ===
Line 100: Line 174:
 
* It would be nice if you could run a buildroot command that prepares a local copy of a package's source, and allows you to generate patches for it later. This could use git or quilt to keep track of the patches.
 
* It would be nice if you could run a buildroot command that prepares a local copy of a package's source, and allows you to generate patches for it later. This could use git or quilt to keep track of the patches.
 
* It would be nice if there was a make target to reinstall everything to the target (i.e. remove all the target-installed stamps, remove the root stamp, maybe remove the target too).  However, what is missing is the copying of the toolchain support files (libc.so etc.).  It's not obvious that this can be done in a reliable way.
 
* It would be nice if there was a make target to reinstall everything to the target (i.e. remove all the target-installed stamps, remove the root stamp, maybe remove the target too).  However, what is missing is the copying of the toolchain support files (libc.so etc.).  It's not obvious that this can be done in a reliable way.
* It would be nice if there was some common infrastructure to combine the images into one final flash or SD card or whatever image.  However, it is probably difficult to find the commonality of all the different use cases.  And we don't even see all these use cases.
 
** Yann E. Morin is working on this topic.
 
 
* To facilitate debugging, all packages should be installed to the staging directory. The target directory should in fact be a subset of the staging directory. See the FOSDEM 2013 discussion at http://elinux.org/Buildroot:DeveloperDaysFOSDEM2013, and the discussion around patch http://patchwork.ozlabs.org/patch/252718/. This is however a significant change in Buildroot, so probably difficult to implement, and will raise a number of quite complicated questions.
 
* To facilitate debugging, all packages should be installed to the staging directory. The target directory should in fact be a subset of the staging directory. See the FOSDEM 2013 discussion at http://elinux.org/Buildroot:DeveloperDaysFOSDEM2013, and the discussion around patch http://patchwork.ozlabs.org/patch/252718/. This is however a significant change in Buildroot, so probably difficult to implement, and will raise a number of quite complicated questions.

Latest revision as of 00:59, 16 November 2023

Buildroot is a nice, simple, and efficient embedded Linux build system.

Important links

Developer days

Upcoming:

Past:

Talks

This section gathers the list of talks given about Buildroot, as well as the slides and video when available.

Past:

List of forks

  • SkiffOS is a modular config layering system for Buildroot with support for 50+ targets.
  • Batocera.linux is an open-source and completely free retro-gaming distribution.
  • Home Assistant Operating System. Home Assistant Operating System (formerly HassOS) is an operating system optimized for hosting Home Assistant and its Add-ons.
  • OpenIL. OpenIL is an open source project based on Buildroot and designed for embedded industrial solution.
  • Bsquask SDK. A Rasberry-Pi related fork.
  • buildroot-rpi. Another RPi related fork, with a lot of focus on Qt5 and GStreamer (appears to be defunct).
  • Buildroot Submodule. Not a fork, but a convenience layer on top of buildroot.
  • Experimental 'shell' around Buildroot. Another wrapper around Buildroot, to help manage projects.

Todo list

This is a list of improvements that we would like to see in buildroot. Feel free to add suggestions here. If you're working on one of these items, put your name and the date behind it, to avoid duplicate work.

There are a number of patches that have been determined to be useful but for various reasons nobody currently has time to review or test them. Anybody, especially a person new to buildroot, is welcome to adopt these patches and resubmit them to the mailing list.

Perpetual work

Some jobs are never finished. When you have a bit of uninterrupted time you would like to spend on Buildroot, you can pick one of these things.

Autobuild failures

The autobuild failures are random configurations for which the build fails. This is what we want to fix. A summary of failures is sent daily to the mailing list, this gives a good summary of the most frequently failing packages.

  • Go to the failing output ("end log" link) and see if it's an error message that you can make sense of. Often you can't, then just skip it and look for something else.
  • Check on patchwork if a fix was already posted. Also check in recent commit history if a fix was already committed. Also ask on IRC if someone is working on it.
  • Reproduce the issue with the br-reproduce-build script. However, it is often easier to first attempt to reproduce it by simply downloading the defconfig as .config, run make olddefconfig, then make <the package that fails>. Not all issues can be reproduced this way however! Also, if the failing configuration was using a Buildroot toolchain rather than an external toolchain, it can be worth to first try to reproduce with an external toolchain (which reduces the build time by quite a lot).
  • Produce a fix. Here are some hints.
    • Perhaps the package simply doesn't support that configuration (target architecture, libc type, static build, threads, GCC version) and a dependency has to be added in Config.in.
    • Sometimes a fix was already found by someone else and sent upstream, so check its bugs list, pull requests and recent commits. Also check if OpenEmbedded has a fix already.
    • Sometimes a similar issue was recently fixed for another package, so you can git log --grep '<some part of the error message>'.
  • Test the fix with the actual configuration (so no switching to external toolchain any more). Do a full clean build.
  • Check your changes with the utils/check-package script.
  • Post your fix according to the contribution guidelines in the manual.

See this commit for an example of what the commit message should look like. Important is to have:

  • the compilation error;
  • the Fixes: line;
  • your Signed-off-by.

Update CVE exceptions

Buildroot keeps track of which CVEs apply to each package, based on a CPE ID. However, many CVEs don't actually apply. In particular very old CVEs are likely not to be applicable to the version currently shipped in Buildroot.

  • Look at the package statistics. Sort by "CVEs". Look for a package with old CVEs.
  • For each CVE, check if it really applies.
  • If not, update the package's FOO_IGNORE_CVES with the CVE to ignore. Commit with a commit message that explains in detail why the CVE can be ignored. Example commit message.
  • If the CVE really applies, check if there is an upstream patch fixing it.
  • Check your changes with the utils/check-package script.
  • Post your fix according to the contribution guidelines in the manual.

Packages

Note: if you start working on any of these packages, please edit this section to indicate it. If the package is proposed in a bug report, please also update the bug report. Sending a mail to the mailing list also never hurts, you never know that someone else started working on it without following this guideline.

Important

Nice to have

Toolchain

Documentation

  • Convert the documentation + the generation workflow from current asciidoc to either markdown or ReStructuredText (people are nowadays more used to that syntax, and they are formatted directly when viewed in gitlab/github).
  • Document how to contribute (how often to repost, what to expect, ...) basic guide
  • Document that package patches should be sent upstream

Core Buildroot infrastructure

  • Cargo and Go post-process handling for vendoring
    • Add support for tarball formats other than gz
  • Several improvements are possible in the download infrastructure (even after all the improvements that were already done):
    • Rename the downloaded files so they include the package name and version. Special care has to be taken for primary and secondary sites, and for extra downloads (including patches).
    • Split between FOO_SITE and FOO_SOURCE shouldn't be necessary. Or it could be made optional, i.e. make it possible to specify the full path in FOO_SOURCE.
  • Add instrumentation scripts to analyse package installed files:
    • find libraries with wrong RPATH/RUNPATH tags
    • detect unused .so libs (eg. shared libs that are not DT_NEEDED by anything - note: only detect those libs, don't remove: can be used as plugin (dlopen), or used by an application built outside Buildroot)
  • A script that checks consistency of depends/select for packages. Maybe it can be integrated to the current check-package.

Testing infrastructure

  • Fix run-tests to use a config file for download and output directories, can be overridden in the environment
  • Documentation on how to add a test, including naming convention

TODO items under discussion

Here are some nice-to-have's for which it is not entirely clear if and how they could be implemented:

  • Out-of-tree builds, which allows the package source to be shared between different output directories and between host and target compiles.
  • It would be nice if you could run a buildroot command that prepares a local copy of a package's source, and allows you to generate patches for it later. This could use git or quilt to keep track of the patches.
  • It would be nice if there was a make target to reinstall everything to the target (i.e. remove all the target-installed stamps, remove the root stamp, maybe remove the target too). However, what is missing is the copying of the toolchain support files (libc.so etc.). It's not obvious that this can be done in a reliable way.
  • To facilitate debugging, all packages should be installed to the staging directory. The target directory should in fact be a subset of the staging directory. See the FOSDEM 2013 discussion at http://elinux.org/Buildroot:DeveloperDaysFOSDEM2013, and the discussion around patch http://patchwork.ozlabs.org/patch/252718/. This is however a significant change in Buildroot, so probably difficult to implement, and will raise a number of quite complicated questions.