mirror of
https://github.com/cirosantilli/linux-kernel-module-cheat.git
synced 2026-01-23 02:05:57 +01:00
buildroot: use our fork for rpath
This commit is contained in:
2
.gitmodules
vendored
2
.gitmodules
vendored
@@ -1,6 +1,6 @@
|
|||||||
[submodule "buildroot"]
|
[submodule "buildroot"]
|
||||||
path = buildroot
|
path = buildroot
|
||||||
url = https://github.com/buildroot/buildroot
|
url = https://github.com/cirosantilli/buildroot
|
||||||
ignore = dirty
|
ignore = dirty
|
||||||
[submodule "qemu"]
|
[submodule "qemu"]
|
||||||
path = qemu
|
path = qemu
|
||||||
|
|||||||
24
README.adoc
24
README.adoc
@@ -6616,23 +6616,15 @@ One way to overcome this problem is to mount benchmarks from host instead of add
|
|||||||
|
|
||||||
Buildroot is not designed for large root filesystem images, and the rebuild becomes very slow when we add a large package to it.
|
Buildroot is not designed for large root filesystem images, and the rebuild becomes very slow when we add a large package to it.
|
||||||
|
|
||||||
This is due mainly to the `pkg-generic` `GLOBAL_INSTRUMENTATION_HOOKS` sanitation which go over the entire tree doing complex operations... I no like, in particular `check_bin_arch` and `check_host_rpath`, which get stuck for a long time on the message:
|
This is due mainly to the `pkg-generic` `GLOBAL_INSTRUMENTATION_HOOKS` sanitation which go over the entire tree doing complex operations... I no like, in particular `check_bin_arch` and `check_host_rpath`
|
||||||
|
|
||||||
|
We have applied link:https://github.com/cirosantilli/buildroot/commit/983fe7910a73923a4331e7d576a1e93841d53812[983fe7910a73923a4331e7d576a1e93841d53812] to out Buildroot fork which removes part of the pain by not running:
|
||||||
|
|
||||||
....
|
....
|
||||||
>>> Sanitizing RPATH in target tree
|
>>> Sanitizing RPATH in target tree
|
||||||
....
|
....
|
||||||
|
|
||||||
The pause is followed by:
|
which contributed to a large part of the slowness.
|
||||||
|
|
||||||
....
|
|
||||||
out/arm/buildroot/build/<pkg>/.stamp_target_installed
|
|
||||||
....
|
|
||||||
|
|
||||||
so which shows that the whole delay is inside our install itself.
|
|
||||||
|
|
||||||
I put an `echo f` in `check_bin_arch`, and it just loops forever, does not stop on a particular package.
|
|
||||||
|
|
||||||
Ignored / declined patch at: http://lists.busybox.net/pipermail/buildroot/2018-May/220662.html I might just fork Buildroot on the submodule if this keeps annoying me.
|
|
||||||
|
|
||||||
=== Report upstream bugs
|
=== Report upstream bugs
|
||||||
|
|
||||||
@@ -7087,9 +7079,13 @@ The action seems to be happening at: `hw/arm/virt.c`.
|
|||||||
***** `out/common/gem5/<variant>/m5out`
|
***** `out/common/gem5/<variant>/m5out`
|
||||||
***** `out/common/gem5/<variant>/system`
|
***** `out/common/gem5/<variant>/system`
|
||||||
|
|
||||||
:leveloffset: +3
|
==== buildroot_patches
|
||||||
|
|
||||||
include::buildroot_patches/README.adoc[]
|
Every `.patch` file in this directory gets applied to Buildroot before anything else is done.
|
||||||
|
|
||||||
|
This directory has been made kind of useless when we decided to use our own Buildroot fork, but we've kept the functionality just in case we someday go back to upstream Buildroot.
|
||||||
|
|
||||||
|
:leveloffset: +3
|
||||||
|
|
||||||
include::global_patch_dir/README.adoc[]
|
include::global_patch_dir/README.adoc[]
|
||||||
|
|
||||||
|
|||||||
Submodule buildroot updated: f3d114a1ef...bc60382b8f
@@ -1,9 +1 @@
|
|||||||
= buildroot_patches
|
https://github.com/cirosantilli/linux-kernel-module-cheat#buildroot_patches
|
||||||
|
|
||||||
Every `.patch` file in this directory gets applied to Buildroot before anything else is done.
|
|
||||||
|
|
||||||
Ideally, this directory should be empty, and we should use only built-in Buildroot configuration mechanisms.
|
|
||||||
|
|
||||||
But alas, life is sometimes not ideal.
|
|
||||||
|
|
||||||
We will use those patches only for things which could / have already been upstreamed. The patches will then be removed once we are able to rebase. Educational patches that we might want to do on QEMU will be done by forking the QEMU repo on our submodule. The difference is that it is a bit easier to remove the patches after upstreaming than to squash them out on rebase.
|
|
||||||
|
|||||||
@@ -1,12 +0,0 @@
|
|||||||
diff --git a/package/qemu/qemu.mk b/package/qemu/qemu.mk
|
|
||||||
index f02df8bcc1..3b139bafa9 100644
|
|
||||||
--- a/package/qemu/qemu.mk
|
|
||||||
+++ b/package/qemu/qemu.mk
|
|
||||||
@@ -224,7 +224,6 @@ define QEMU_CONFIGURE_CMDS
|
|
||||||
./configure \
|
|
||||||
--prefix=/usr \
|
|
||||||
--cross-prefix=$(TARGET_CROSS) \
|
|
||||||
- --with-system-pixman \
|
|
||||||
--audio-drv-list= \
|
|
||||||
--enable-kvm \
|
|
||||||
--enable-attr \
|
|
||||||
Reference in New Issue
Block a user