ee5e14ff17
A (target [0]) package can independently declare installing in various locations: target, staging, or images. The default is to only install in target. When a package opts out from installing to target, but does not opts in to install in any other location, the package is not downloaded, extracted, patched, configured, nor built at all. As a consequence, none of the per-step instrumentation is executed, specifically the listing of files before/after the package sequence. Down the line, the package infra does not cope well with that situation, because the gathering-install step, the one that synchronises all the optional target, staging, or images install steps, still gets run. And as #13836 shows, this does not go well: /bin/sh: /home/tbuild/myboard/build/foo/.files-list.after: No such file or directory make[1]: *** [/home/tbuild/myboard/build/foo/.stamp_installed] Error 1 make: *** [_all] Error 2 So, we should have ensured that the gathering-install step itself depends on the build step, which would have solved the issue. However, this bug really illustrates a more fundamental issue: does it even make sense to have a package that installs nothing in any location? Indeed, why even bother with that package to begin with if it will not provide anything at all? It turns out that yes, this makes sense. We have some packages, that do not install anything at all, and do not even build anything; they are there just to ensure that we can download something that will ultimately be used by another package. This is the case for example for packages that provide linux extensions, like aufs [1]. Additionally, some ugly out-of-tree packages could conceivably install things during the build (or even configure!) steps. That's not unheard of... [2] So, the solution is to ensure that the gathering-install step does depend on the build step, to trigger the proper dependency chain and have the instrumentation hooks properly run even in that degenerate case. Fixes: #13836 [0] a host package can't opt out of installing anything. [1] that one is actually missing AUFS_INSTALL_TARGET = NO, so this hides the issue. [2] even us are not 100% clean on that topic: gcc will install files in staging and target as part of the same step (not the build, granted, but still...) Reported-by: "Weber, Matthew L Collins" <Matthew.Weber@collins.com> Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr> Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Tested-by: Matthew Weber <matthew.weber@collins.com Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr> |
||
---|---|---|
arch | ||
board | ||
boot | ||
configs | ||
docs | ||
fs | ||
linux | ||
package | ||
support | ||
system | ||
toolchain | ||
utils | ||
.defconfig | ||
.flake8 | ||
.gitignore | ||
.gitlab-ci.yml | ||
CHANGES | ||
Config.in | ||
Config.in.legacy | ||
COPYING | ||
DEVELOPERS | ||
Makefile | ||
Makefile.legacy | ||
README |
Buildroot is a simple, efficient and easy-to-use tool to generate embedded Linux systems through cross-compilation. The documentation can be found in docs/manual. You can generate a text document with 'make manual-text' and read output/docs/manual/manual.text. Online documentation can be found at http://buildroot.org/docs.html To build and use the buildroot stuff, do the following: 1) run 'make menuconfig' 2) select the target architecture and the packages you wish to compile 3) run 'make' 4) wait while it compiles 5) find the kernel, bootloader, root filesystem, etc. in output/images You do not need to be root to build or run buildroot. Have fun! Buildroot comes with a basic configuration for a number of boards. Run 'make list-defconfigs' to view the list of provided configurations. Please feed suggestions, bug reports, insults, and bribes back to the buildroot mailing list: buildroot@buildroot.org You can also find us on #buildroot on OFTC IRC. If you would like to contribute patches, please read https://buildroot.org/manual.html#submitting-patches