mirror of
https://gitlab.com/buildroot.org/buildroot.git
synced 2026-08-18 21:33:39 -09:00
f6c0475732
Currently, the gdbinit is generated and installed during post install hooks, either from the gdb package, or from the external-toolchain package. When using per-package directories (PPD), the staging directory of the either package is stored in the generated gdbinit, which is not going to be valid when all the PPD staging dirs get merged into the final staging: it would lack any library installed afterwards, i.e. mostly everything would be missing (but the libraries from the C toolchain in the case of an external toolchain). Similarly, all the RPATH will point to various PPD drectories. This does not cause any issue when the final host is aggregated, because the PPD directories still exist when we call programs from there (e.g. from the fs infra, or from post-image scripts). However, we knew that would not always be possible to keep the PPD directories: we have the prepare-sdk rule that runs a cleanup pass on the RPATH, and also applies the generic PPD fixups. When we introduced prepare-sdk inc32ad51cbf(core/sdk: generate the SDK tarball ourselves), we did not yet have support for PPD for the host directory, and especially, we did not have the host-finalize rule, which was only introduced ind0f4f95e39(Makefile: rework main directory creation logic) which kick-started the introduction of PPD. At that point, we did not realise that the rpath fixups from prepare-sdk, would be better moved to the new host-finalize rule, because that had no impact unless one would need an SDK. Later, in25e60fbe1c(Makefile: fix SDK relocation for per-package-dirs), we eventually introduced the PPD generic fixups in the prepare-sdk rule. Again, we did not realise that those fixups would be better placed in the host-finalize rule rather than the prepare-sdk. While fixing the RPATH in host-finalize is not critical, fixing up the PPD paths actually is, as the gdbinit case demonstrate. As such, move the PPD fixups to the host-finalize step, and while at it, also move the RPATH fixups. This now does not leave much to do in the prepare-sdk step, and that could very well be moved to the host-finalize rule as well. However, some people may have started to rely on prepare-sdk in its 6 years of existence, and the little script it installs is not needed unless one really needs an SDK. So leave it as it is for now. Reported-by: Casey Reeves <casey@xogium.me> Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr> Tested-by: Casey Reeves <casey@xogium.me> Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Cc: Brandon Maier <Brandon.Maier@collins.com> Tested-by: Brandon Maier <brandon.maier@collins.com> Acked-by: TIAN Yuanhao <tianyuanhao3@163.com> (cherry picked from commita87abcf6da) Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
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