Difference between revisions of "Buildroot"

From eLinux.org
Jump to: navigation, search
(Core Buildroot infrastructure)
(Developer days)
(32 intermediate revisions by 10 users not shown)
Line 10: Line 10:
 
== Developer days ==
 
== Developer days ==
  
Upcoming:
+
Future:
* [[Buildroot:DeveloperDaysELCE2014 | Buildroot Developer Days]], October 2014, Düsseldorf, Germany, before or after ELC-E.
+
* Buildroot Developer Days, 8-9 October 2016, Berlin, Germany, after [http://events.linuxfoundation.org/events/embedded-linux-conference-europe ELCE].
  
 
Past:
 
Past:
 +
* [[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 24: Line 28:
  
 
This section gathers the list of talks given about Buildroot, as well as the slides and video when available.
 
This section gathers the list of talks given about Buildroot, as well as the slides and video when available.
 
Upcoming:
 
* "Buildroot: a deep dive into the core", Thomas Petazzoni, Embedded Linux Conference Europe, 13-15 October 2014, Düsseldorf, Germany
 
  
 
Past:
 
Past:
* [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].
+
* "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].
 
* "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].
 +
 +
==Accounting==
 +
 +
This section gathers all the income and expenses of the Buildroot project.
 +
 +
Current balance: + €423.14
 +
 +
* 2015-01-08: + €423.14 : Google paid €423.14 ($500) for mentoring a student for the GSoC 2014
 +
* 2016-02-07: - € 42.10 : thank-you gift to Niel for helping host the DevDays in Brussels the past few years (T-Shirt: €24.50, Mug: €10.00, shipping: €14.50, rebate: €6.90)
 +
 +
''Notes: until we have a legal entity representing Buildroot, that money is held by Yann E. MORIN on behalf the Buildroot project. Accounting is handled in Euro.''
  
 
==List of forks==
 
==List of forks==
Line 36: Line 49:
 
* [https://github.com/nezticle/RaspberryPi-BuildRoot]. A Rasberry-Pi related fork.
 
* [https://github.com/nezticle/RaspberryPi-BuildRoot]. A Rasberry-Pi related fork.
 
* [https://github.com/albertd/buildroot-rpi]. Another RPi related fork, with a lot of focus on Qt5 and GStreamer.
 
* [https://github.com/albertd/buildroot-rpi]. Another RPi related fork, with a lot of focus on Qt5 and GStreamer.
 +
* [https://github.com/Openwide-Ingenierie/buildroot-submodule]. Not a fork, but a convenience layer on top of buildroot.
 +
* [http://ymorin.is-a-geek.org/git/buildroot.config/]. Another wrapper around Buildroot, to help manage projects.
  
 
==Todo list==
 
==Todo list==
Line 47: Line 62:
 
'''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.
+
* Create a package for the Qt5 demo/benchmark application at https://github.com/prabindh/xgxperf. Ricardo Martincoski is working on this.
* Create a package for the Qt5 Cinematic Experience demonstration. See http://quitcoding.com/?page=work.
 
* Create a package for the Qt5 demo/benchmark application at https://github.com/prabindh/xgxperf.
 
* Enable MIPS32 and MIPS64 support in Valgrind
 
* 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.
 
* 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.
 +
** Picked up by [[User:Smipi01|Pieter Smith]]. Progress can be followed on https://github.com/smipi1/bbb_buildroot/tree/support_2nd_barebox_build.
 
* 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
Line 58: Line 70:
 
** ratpoison https://bugs.busybox.net/show_bug.cgi?id=325
 
** 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. Being worked on by Eric Le Bihan.
 
* Update the webkitgtk package to a more recent version. Being worked on by Eric Le Bihan.
 
 
* Cleanup the libcgi package, by using https://github.com/rafaelsteil/libcgi as an upstream.
 
* 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.
 
* 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.
 
* Merge qemu and qemu-system patches in patchwork, see http://patchwork.ozlabs.org/patch/345358/ http://patchwork.ozlabs.org/patch/345359/ http://patchwork.ozlabs.org/patch/345360/ and http://patchwork.ozlabs.org/patch/299014/ http://patchwork.ozlabs.org/patch/319108/
 
* Merge qemu and qemu-system patches in patchwork, see http://patchwork.ozlabs.org/patch/345358/ http://patchwork.ozlabs.org/patch/345359/ http://patchwork.ozlabs.org/patch/345360/ and http://patchwork.ozlabs.org/patch/299014/ http://patchwork.ozlabs.org/patch/319108/
 
* Update polkit and udisks. Updating polkit is complicated since starting from version 106, they depend on Spidermonkey, the Javascript engine from Mozilla. Maxime Hadjinlian is working on this.
 
* Update polkit and udisks. Updating polkit is complicated since starting from version 106, they depend on Spidermonkey, the Javascript engine from Mozilla. Maxime Hadjinlian is working on this.
* In uClibc package, make sure we disable the HAVE_SHARED option when BR2_PREFER_STATIC_LIB is enabled. Thomas Petazzoni will take care of this.
 
  
 
=== Documentation ===
 
=== Documentation ===
Line 71: Line 80:
 
* Document how a package patch should be formatted (Comment, SOB, file naming rules, ...) + send upstream + CC sendpatches
 
* Document how a package patch should be formatted (Comment, SOB, file naming rules, ...) + send upstream + CC sendpatches
 
* In documentation, explain how to report a bug
 
* In documentation, explain how to report a bug
* Upgrade the buildroot website (ThomasP has a mockup of a new website)
 
  
 
=== Build/release infrastructure ===
 
=== Build/release infrastructure ===
Line 79: Line 87:
 
=== Core Buildroot infrastructure ===
 
=== Core Buildroot infrastructure ===
  
* ldconfig handling is broken, see http://patchwork.ozlabs.org/patch/255486/
+
* 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.
 +
** Conserve downloaded git/hg trees, so that you can change the FOO_VERSION and avoid a re-download. This requires using 'git fetch URL' instead of 'git clone URL' when the .git directory exists already.
  
 
* 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]
 
* 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]
 
* Add a 'make <package>-help' target.
 
  
 
* 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).
 
* 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).
Line 115: Line 124:
 
* 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.

Revision as of 08:05, 7 February 2016

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

Important links

Developer days

Future:

  • Buildroot Developer Days, 8-9 October 2016, Berlin, Germany, after ELCE.

Past:

Talks

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

Past:

  • "Buildroot: a deep dive into the core", Thomas Petazzoni, Embedded Linux Conference Europe, 13-15 October 2014, Düsseldorf, Germany. Slides.
  • Buildroot: what's new, Thomas Petazzoni, Embedded Linux Conference, 1 May 2014, San Jose, United States. Slides, HD video, Low-res video, Audio only
  • "Buildroot: what is new", Peter Korsgaard, Embedded Linux Conference Europe, 25 October 2013, Edinburgh, UK. Slides, Video.

Accounting

This section gathers all the income and expenses of the Buildroot project.

Current balance: + €423.14

  • 2015-01-08: + €423.14 : Google paid €423.14 ($500) for mentoring a student for the GSoC 2014
  • 2016-02-07: - € 42.10 : thank-you gift to Niel for helping host the DevDays in Brussels the past few years (T-Shirt: €24.50, Mug: €10.00, shipping: €14.50, rebate: €6.90)

Notes: until we have a legal entity representing Buildroot, that money is held by Yann E. MORIN on behalf the Buildroot project. Accounting is handled in Euro.

List of forks

  • [1]. A Rasberry-Pi related fork.
  • [2]. Another RPi related fork, with a lot of focus on Qt5 and GStreamer.
  • [3]. Not a fork, but a convenience layer on top of buildroot.
  • [4]. 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. These patches can be viewed by looking at the following link - http://patchwork.ozlabs.org/project/buildroot/list/?state=1&delegate=7151

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.

Documentation

  • 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, ...) basic guide
  • Document how a package patch should be formatted (Comment, SOB, file naming rules, ...) + send upstream + CC sendpatches
  • In documentation, explain how to report a bug

Build/release infrastructure

  • Peter sets up a planet on whatever server and links to it from buildroot website

Core Buildroot infrastructure

  • 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.
    • Conserve downloaded git/hg trees, so that you can change the FOO_VERSION and avoid a re-download. This requires using 'git fetch URL' instead of 'git clone URL' when the .git directory exists already.
  • 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).
  • Make the HOST-directory a relocatable SDK:
    • 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.
    • Change the rpath value to $ORIGIN/../lib instead of the current absolute path $(O)/host/usr/lib.
    • 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)
  • Add intrumentation 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
    • 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 checkpackage script that verifies a package coding style (e.g. 80 # in the .mk file, indentation with tabs, ...). It could also check consistency of depends/select though that's a bit more advance.

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.