a1d602a74d
Running pseudo is more involved than running fakeroot. In the transition from using fakeroot, we just did not account for the extra requirements. First, we explicitly tell pseudo where it is, otherwise it tries to guess. Its guess is correct, but it prints a warning, which is not nice. Second, we tell it where to find the passwd and group files in case it has to emulate access to them. We currently do not use that feature, but better safe than sorry. Third, pseudo spawns a background daemon, and talks to it (when fakeroot would emulate the state all in the current process' state, pseudo uses the daemon to coordinate the state across multiple processes). We are not much interested in the daemon lingering around, so we just tell it to terminate as soon as the last clients quits (this can take up to one second). Fourth and last, pseudo always stores its internal database when exiting, and reloads it when spawned. The database is by default stored in a sub-directory of the prefix it was installed in, but this is impractical for us. We want the database to be specific to the one config dir we are building, so we store the database in a (hidden) sub-dir of the build dir, thus ensuring it is never shared with another build. That directory is hidden (starts with a dot) because we consider that to be our internal state that we do not want to expose to the user. The wrapper has to be relocatable, so we avoid using hard-coded paths in there: we derive those paths fom the runtime path of pseudo. However, the build directory $(BUILD_DIR) is not available in the environment (we do not export it because it conflicts with some buildsystems). Instead, we use $(BASE_DIR) which is exported. Finally, when relocated, the wrapper would not be used in the Buildroot environment, so may not have access to TARGET_DIR or BASE_DIR, unless the user sets them. If he does not, we still want the wrapper to be working (to avoid the warning about the prefix, and to exit the daemon asap); thus we leave the passwd and localstatedir variable alone if we don't have what it needs to set them, rather than set them to incorrect values. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Gaël PORTAY <gael.portay@savoirfairelinux.com> Cc: Patrick Keroulas <patrick.keroulas@savoirfairelinux.com> Cc: Erico Nunes <nunes.erico@gmail.com> Cc: Julien BOIBESSOT <julien.boibessot@free.fr> Cc: Arnout Vandecappelle <arnout@mind.be> Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> |
||
|---|---|---|
| arch | ||
| board | ||
| boot | ||
| configs | ||
| docs | ||
| fs | ||
| linux | ||
| package | ||
| support | ||
| system | ||
| toolchain | ||
| .defconfig | ||
| .gitignore | ||
| 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 Freenode IRC. If you would like to contribute patches, please read https://buildroot.org/manual.html#submitting-patches