linux/poky.git/meta/classes, branch yocto-4.0.20

linuxloader: add -armhf on arm only for TARGET_FPU 'hard'

2024-07-09T13:06:09+00:00

There are two types of soft FPU options for arm, soft and softfp, and if using the latter the wrong dynamic loader will be used. E.g. go will link against ld-linux-armhf.so.3, but libc6 will only ship a ld-linux.so.3, so go programs will fail to start. Fix this by instead checking for TARGET_FPU being 'hard' and then applying the suffix. (From OE-Core rev: c7426629245db2ea8d9f3cf25b575ac31b5a83b0) Signed-off-by: Jonas Gorski Signed-off-by: Richard Purdie (cherry picked from commit 07b4c7a2bd23f8645810e13439e814caaaf9cd94) Signed-off-by: Steve Sakoman

classes: go-mod: do not pack go mod cache

2024-05-29T12:24:08+00:00

Clean go module cache from builddir to prevent it of beeing packed. (From OE-Core rev: c850931590ff22da4d38756f957b88e04078c76c) Signed-off-by: Stefan Herbrechtsmeier Signed-off-by: Lukas Funke Signed-off-by: Alexandre Belloni (cherry picked from commit 328bea56dec8f83b5c118f567e122510f9243087) Signed-off-by: Jose Quaresma Signed-off-by: Steve Sakoman

go.bbclass: fix path to linker in native Go builds

2024-05-29T12:24:08+00:00

Building native Go tools results in the tool pointing to the wrong location of dynamic linker (see below). The linker is looked up in the temporary dir, which can be removed if rm_work is inherited. This results in being unable to execute the program with the 'No such file or directory' error. Override linker specificiation for native recipes (and let Go build environment to pick up a correct one on it's own). The error is observed in case the distro doesn't use uninative.bbclass. If uninative.bbclass is used, the binary will be patched automatically to use the uninative loader instead of the system one. Without this patch: $ ldd tmp-rpb-glibc/sysroots-components/x86_64/go-md2man-native/usr/bin/go-md2man linux-vdso.so.1 (0x00007ffe945ec000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f3a7490e000) /home/lumag/Projects/RPB/build-rpb/tmp-rpb-glibc/work/x86_64-linux/go-md2man-native/1.0.10+gitAUTOINC+f79a8a8ca6-r0/recipe-sysroot-native/usr/lib/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x00007f3a74d13000) $ tmp-rpb-glibc/sysroots-components/x86_64/go-md2man-native/usr/bin/go-md2man --help -bash: tmp-rpb-glibc/sysroots-components/x86_64/go-md2man-native/usr/bin/go-md2man: No such file or directory With the patch $ ldd tmp-rpb-glibc/sysroots-components/x86_64/go-md2man-native/usr/bin/go-md2man linux-vdso.so.1 (0x00007ffd19dbf000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f2d44181000) /lib64/ld-linux-x86-64.so.2 (0x00007f2d44586000) $ tmp-rpb-glibc/sysroots-components/x86_64/go-md2man-native/usr/bin/go-md2man --help Usage of tmp-rpb-glibc/sysroots-components/x86_64/go-md2man-native/usr/bin/go-md2man: -in string Path to file to be processed (default: stdin) -out string Path to output processed file (default: stdout) (From OE-Core rev: b611c77e4883ad81a8f40cbee3fea006500735ed) Signed-off-by: Dmitry Baryshkov Signed-off-by: Richard Purdie (cherry picked from commit 44b397daa68b4d0a461225fe9ff7db8b5fcfdb7b) Signed-off-by: Jose Quaresma Signed-off-by: Steve Sakoman

go: Always pass interpreter to linker

2024-05-29T12:24:08+00:00

When gos internal linker is used, it uses hardcoded paths to the interpreter (dynamic linker). For x86_64 this hardcoded path is /lib64/ld-linux-x86-64.so.2, but yocto's default dynamic linker path is /lib64/ld-linux-x86-64.so.2. Most of the time, the internal linker is not used and binutils linker sets the correct path, but sometimes the internal linker is used and the resulting binary will not work on x86_64. To ensure the path is always correct, pass it to the linker. (From OE-Core rev: 69128ca66991b13358f2552fcd5a7cfa6dda4952) Signed-off-by: Joerg Vehlow Signed-off-by: Alexandre Belloni Signed-off-by: Richard Purdie (cherry picked from commit 6b54215074d7f3dbba07f096f16b9c0acf51527c) Signed-off-by: Jose Quaresma Signed-off-by: Steve Sakoman

kernel.bbclass: check, if directory exists before removing empty module directory

2024-05-15T16:44:16+00:00

If the kernel folder does not exist, find will result in an error. This can occur if the kernel has no modules but, for example, custom modules are created. Add check before deleting. (From OE-Core rev: 4e4681b26e0d88ad219d72b75e598e6b81b430fc) Signed-off-by: Heiko Thole Signed-off-by: Alexandre Belloni Signed-off-by: Richard Purdie (cherry picked from commit 7ef767d84d56b25498e45db83bb8f9d9caebeaf9) Signed-off-by: Steve Sakoman

rootfs-postcommands.bbclass: Only set DROPBEAR_RSAKEY_DIR once

2024-05-02T13:21:09+00:00

If DROPBEAR_RSAKEY_DIR has already been set before, e.g. by overwriting the file dropbear.default, the line will still be appended a second time. DROPBEAR_RSAKEY_DIR="/path/to/dropbear" DROPBEAR_EXTRA_ARGS="-B" DROPBEAR_RSAKEY_DIR=/var/lib/dropbear (Backport of rev: 6045314d2968f6f5a0877a4dd45f35c766a40e40) (From OE-Core rev: 8a502301209ef144932ef5071c1a9b738db23270) Signed-off-by: Michael Glembotzki Signed-off-by: Steve Sakoman

u-boot: Move UBOOT_INITIAL_ENV back to u-boot.inc

2024-03-12T14:06:19+00:00

Commit cc6c3e31526d ("u-boot: Move definitions to common locations") moved UBOOT_INITIAL_ENV to uboot-config.bbclass, but it should be kept at u-boot.inc because it encodes ${PN} in it, which should be set by the U-Boot recipe. Currently, whatever inherits uboot-config bbclass will fill-in its own PN, which would change the content of UBOOT_INITIAL_ENV per-package. Cc: Klaus Heinrich Kiwi Cc: Marek Vasut Fixes: cc6c3e31526d ("u-boot: Move definitions to common locations") (From OE-Core rev: 18b76259d27dc045f621cd512582c37e8bbab45c) Signed-off-by: Fabio Estevam Backported from master: 0b0c4b37d318b86f100512476ffd861e0ce1f47e Signed-off-by: Fabio Estevam Signed-off-by: Steve Sakoman

kernel.bbclass: Set pkg-config variables for building modules

2024-03-07T18:32:54+00:00

[Backport cd2072e5d953 from the master without HOSTPKG_CONFIG setting] The pkg-config workaround has been applied for kernel image building, but not for module building. So pkg-config variables are different between do_compile and do_compile_kernelmodules tasks. It may unnecessary trigger rebuilding of a few host tools at the later task. Especially when CONFIG_DEBUG_INFO_BTF is enabled in the kernel, it may even trigger rebuilding vmlinux at do_compile_kernelmodules due to the rebuilt host tools such as certs/extract-cert or objtool (on x86). This eventually creates an inconsistent set of kernel binaries. Here is the repro steps: - Check out nanbield on x86 - The unexpected rebuild happens on kirkstone or possibly earlier - Ensure that pahole is available (e.g. via meta-oe) - Set KERNEL_DEBUG to "True" to properly set up PAHOLE e.g. $ export KERNEL_DEBUG="True" $ export BB_ENV_PASSTHROUGH_ADDITIONS="${BB_ENV_PASSTHROUGH_ADDITIONS} KERNEL_DEBUG" - Enable CONFIG_DEBUG_INFO_BTF=y e.g. $ bitbake -c menuconfig virtual/kernel -> Kernel hacking -> Compile-time checks and compiler options -> Generate BTF typeinfo - Build the kernel e.g. $ bitbake virtual/kernel The BTF information in the resulting bzImage and kernel modules are inconsistent, because the module's BTF information is generated using the "second" vmlinux that doesn't have the identical BTF to the "first" vmlinux. These modules can't be loaded at runtime due to the BTF mismatch. This also leads to a build-id mismatch between the installed bzImage and vmlinux since the bzImage is created from the first vmlinux, but the installed vmlinux is the second one. $ eu-readelf -n tmp/work/qemux86_64-poky-linux/linux-yocto/6.5.13+git/image/boot/{bzImage*,vmlinux*} | grep "Build ID" Build ID: 4a0d62ee7fef0244950f0f604253729875bea493 Build ID: fb99b3d91399dbe42bf67ddee59e0f5a0c7f74d9 To avoid the unexpected rebuilding that results in such inconsistency, set the same pkg-config variables when building kernel and modules. For kernel 5.19 and above, simply set the HOSTPKG_CONFIG in the make command line. (From OE-Core rev: d63af11e92094487d6e358f27283e5385937e7a8) Signed-off-by: Munehisa Kamata Signed-off-by: Richard Purdie Signed-off-by: Steve Sakoman

kernel: make LOCALVERSION consistent between recipes

2024-03-01T15:19:54+00:00

The initial fix for localversion setting in 6.3+ broke older recipes and also broke recipes setting localversion in a kernel recipe, as make-mod-scripts (and other locations) can trigger a regeneration of files and don't have access to the variable. Moving the setting of this variable to the global namespace doesn't make sense, so we follow the example of the kernel-abiversion and save a kernel-localversion to the build artifacts. Recipes that may regenerate scripts/dynamic files, must depend on the do_shared_workedir of the kernel and use the helper function to read the file storing the localversion. (From OE-Core rev: cca0971a7d92d823cc0c2b16cf14a7b2ed8ecb61) Signed-off-by: Bruce Ashfield Signed-off-by: Alexandre Belloni cherry-picked from master b378eec156998eea55ba61e59103cb34fab0d07c Signed-off-by: Andreas Helbech Kleist Acked-by: Ryan Eatmon Signed-off-by: Steve Sakoman

kernel: fix localversion in v6.3+

2024-03-01T15:19:54+00:00

During testing of the v6.4 reference kernel, it was noticed that on-target modules no longer matched the magic value of the running kernel. This was due to a different localversion in the cross built kernel and the scripts / resources created on target. This was due to changes in the setlocalversion script introduced in the v6.3 series. The .scmversion file is no longer used (or packaged) to inhibit the addition of a "+" (through querying of the git status of the kernel) or the setting of a local version. We recently introduced the KERNEL_LOCALVERSION variable to allow recipes to place a value in .scmversion, so we extend the use of that variable to kernel-arch.bbclass and use it to set the exported variable LOCALVERSION. We must do it at the kernel-arch level, as the variable must be exported in any kernel build to ensure that setlocalversion always correctly sets the localversion. (From OE-Core rev: 74897e505db19a23a5b864a48a4fa97d657605c8) Signed-off-by: Bruce Ashfield Signed-off-by: Richard Purdie cherry-picked from master 765b13b7305c8d2f222cfc66d77c02e6a088c691 Signed-off-by: Andreas Helbech Kleist Signed-off-by: Steve Sakoman