Re: [yocto] Recipe for include-what-you-use and rpath problem #sdk
On 6/25/21 7:00 AM, Francesco Cusolito wrote:
I was able to make it work correctly enabling |CMAKE_SKIP_RPATH|.
Here the working full recipe:
this is fine, if you are interested submit it as a patch to include in
metadata in meta-python
|LICENSE = "NCSA" LIC_FILES_CHKSUM =
"file://LICENSE.TXT;md5=59d01ad98720f3c50d6a8a0ef3108c88 \
file://iwyu-check-license-header.py;md5=cdc4ab52c0b26e216cbf434649d30403" SRC_URI
=
"git://github.com/include-what-you-use/include-what-you-use.git;protocol=https;branch=clang_10"
PV = "0.14+git${SRCPV}" SRCREV = "0.14" S = "${WORKDIR}/git" DEPENDS =
"clang" inherit cmake python3native EXTRA_OECMAKE_append_class-nativesdk
= " \ -DCMAKE_SKIP_RPATH:BOOL=ON \ " BBCLASSEXTEND_append = " \
nativesdk \ " |
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#53981): https://lists.yoctoproject.org/g/yocto/message/53981
Mute This Topic: https://lists.yoctoproject.org/mt/83279588/21656
Mute #sdk:https://lists.yoctoproject.org/g/yocto/mutehashtag/sdk
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] Hardknott (GCC10) Compiler Issues
> GCCVERSION = "9.%" Basically, do NOT use this instruction anywhere. It clearly does NOT work?! I did replace the whole gcc/ in the: poky/meta/recipes-devtools/gcc for hardknott branch: Now I have a gcc_11.1 compiler (from master branch), instead of gcc_10.2. poky/meta/recipes-devtools/gcc [vuser@fedora33-ssd projects_yocto]$ cd bbb-yocto-hardknott/poky/meta/recipes-devtools/gcc [vuser@fedora33-ssd gcc]$ ls -al total 180 drwxr-xr-x. 3 vuser vboxusers 4096 Jun 25 13:50 . drwxr-xr-x. 94 vuser vboxusers 4096 Jun 25 14:45 .. drwxr-xr-x. 2 vuser vboxusers 4096 Jun 25 13:50 gcc -rw-r--r--. 1 vuser vboxusers 800 Jun 25 13:50 gcc_11.1.bb -rw-r--r--. 1 vuser vboxusers 5330 Jun 25 13:50 gcc-11.1.inc -rw-r--r--. 1 vuser vboxusers 4560 Jun 25 13:50 gcc-common.inc -rw-r--r--. 1 vuser vboxusers 4426 Jun 25 13:50 gcc-configure-common.inc -rw-r--r--. 1 vuser vboxusers66 Jun 25 13:50 gcc-cross_11.1.bb -rw-r--r--. 1 vuser vboxusers77 Jun 25 13:50 gcc-cross-canadian_11.1.bb -rw-r--r--. 1 vuser vboxusers 6971 Jun 25 13:50 gcc-cross-canadian.inc -rw-r--r--. 1 vuser vboxusers 6383 Jun 25 13:50 gcc-cross.inc -rw-r--r--. 1 vuser vboxusers73 Jun 25 13:50 gcc-crosssdk_11.1.bb -rw-r--r--. 1 vuser vboxusers 429 Jun 25 13:50 gcc-crosssdk.inc -rw-r--r--. 1 vuser vboxusers 9593 Jun 25 13:50 gcc-multilib-config.inc -rw-r--r--. 1 vuser vboxusers67 Jun 25 13:50 gcc-runtime_11.1.bb -rw-r--r--. 1 vuser vboxusers 12398 Jun 25 13:50 gcc-runtime.inc -rw-r--r--. 1 vuser vboxusers 271 Jun 25 13:50 gcc-sanitizers_11.1.bb -rw-r--r--. 1 vuser vboxusers 4407 Jun 25 13:50 gcc-sanitizers.inc -rw-r--r--. 1 vuser vboxusers 208 Jun 25 13:50 gcc-shared-source.inc -rw-r--r--. 1 vuser vboxusers 113 Jun 25 13:50 gcc-source_11.1.bb -rw-r--r--. 1 vuser vboxusers 1468 Jun 25 13:50 gcc-source.inc -rw-r--r--. 1 vuser vboxusers 8598 Jun 25 13:50 gcc-target.inc -rw-r--r--. 1 vuser vboxusers 4924 Jun 25 13:50 gcc-testsuite.inc -rw-r--r--. 1 vuser vboxusers 143 Jun 25 13:50 libgcc_11.1.bb -rw-r--r--. 1 vuser vboxusers 5175 Jun 25 13:50 libgcc-common.inc -rw-r--r--. 1 vuser vboxusers 1785 Jun 25 13:50 libgcc.inc -rw-r--r--. 1 vuser vboxusers 151 Jun 25 13:50 libgcc-initial_11.1.bb -rw-r--r--. 1 vuser vboxusers 2020 Jun 25 13:50 libgcc-initial.inc -rw-r--r--. 1 vuser vboxusers68 Jun 25 13:50 libgfortran_11.1.bb -rw-r--r--. 1 vuser vboxusers 2574 Jun 25 13:50 libgfortran.inc [vuser@fedora33-ssd gcc]$ Waiting for the compilation results (still compiles). Zee ___ On Fri, Jun 25, 2021 at 10:15 AM Zoran via lists.yoctoproject.org wrote: > > > I have no idea if this is possible in the current YOCTO development stage: > > GCCVERSION = "11.%" > > To do the FF to GCC 11.> > > WARNING: preferred version 11.% of gcc-runtime not available (for item libg2c) > WARNING: versions of gcc-runtime available: 10.2.0 > > For hardknott. Guess, this answers my later question. > > Let us see about my very first question! > > BR, > Zee > ___ > > INCLUDED: > WARNING: preferred version 11.% of gcc-runtime not available (for item > libssp-dev) > WARNING: versions of gcc-runtime available: 10.2.0 > WARNING: preferred version 11.% of gcc-runtime not available (for item > libg2c-dev) > WARNING: versions of gcc-runtime available: 10.2.0 > WARNING: preferred version 11.% of gcc-runtime not available (for item libssp) > WARNING: versions of gcc-runtime available: 10.2.0 > > Build Configuration: > BB_VERSION = "1.50.0" > BUILD_SYS= "x86_64-linux" > NATIVELSBSTRING = "fedora-33" > TARGET_SYS = "arm-poky-linux-gnueabi" > MACHINE = "beaglebone" > DISTRO = "poky" > DISTRO_VERSION = "3.3.1" > TUNE_FEATURES= "arm vfp cortexa8 neon callconvention-hard" > TARGET_FPU = "hard" > meta > meta-poky > meta-yocto-bsp = "hardknott:74dbb08c3709fec6563ee65a3661f66fdcbb3e2f" > meta-jumpnow = "hardknott:ac90f018ebb9de8d6ac12f22368e004aa7be69a2" > meta-bbb = "hardknott:d838aa54e3ed81d08597c08e112fc8966aaa501d" > meta-oe > meta-python > meta-networking = "hardknott:aca88908fd329f5cef6f19995b072397fb2d8ec6" > meta-qt5 = > "upstream/hardknott:a00af3eae082b772469d9dd21b2371dd4d237684" > meta-socketcan = "master:cefd86cd1def9ad2e63be527f8ce36a076d7e17c" > > NOTE: Fetching uninative binary shim > http://downloads.yoctoproject.org/releases/uninative/3.2/x86_64-nativesdk-libc.tar.xz;sha256sum=3ee8c7d55e2d4c7ae3887cddb97219f97b94efddfeee2e24923c0cb0e8ce84c6 > (will check PREMIRRORS first) > Initialising tasks: 100% > |###| > Time: 0:00:11 > Sstate summary: Wanted 1709 Local 0 Network 0 Missed 1709 Current 0 (0% > match, 0% complete) > NOTE: Executing Tasks > > > On Fri, Jun 25, 2021 at 7:58 AM Zoran via lists.yoctoproject.org > wrote: >> >> An interesting issue, and I think I hit it as well (my best
Re: [yocto] Recipe for include-what-you-use and rpath problem #sdk
I was able to make it work correctly enabling CMAKE_SKIP_RPATH.
Here the working full recipe:
LICENSE = "NCSA"
LIC_FILES_CHKSUM = "file://LICENSE.TXT;md5=59d01ad98720f3c50d6a8a0ef3108c88 \
file://iwyu-check-license-header.py;md5=cdc4ab52c0b26e216cbf434649d30403"
SRC_URI =
"git://github.com/include-what-you-use/include-what-you-use.git;protocol=https;branch=clang_10"
PV = "0.14+git${SRCPV}"
SRCREV = "0.14"
S = "${WORKDIR}/git"
DEPENDS = "clang"
inherit cmake python3native
EXTRA_OECMAKE_append_class-nativesdk = " \
-DCMAKE_SKIP_RPATH:BOOL=ON \
"
BBCLASSEXTEND_append = " \
nativesdk \
"
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#53979): https://lists.yoctoproject.org/g/yocto/message/53979
Mute This Topic: https://lists.yoctoproject.org/mt/83279588/21656
Mute #sdk:https://lists.yoctoproject.org/g/yocto/mutehashtag/sdk
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[yocto] [meta-rockchip][PATCH] conf/machine/include/rockchip-wic.inc: create
Create a conf/machine/include/rockchip-wic.inc file to contain all the common
wic/wks things for easy inclusion by any MACHINEs that use wic for their image
creation.
NOTE: the wic image type of rock-pi-e changed from "wic.xz" to "wic" which
matches all the other meta-rockchip MACHINEs that use wic
The following variables were checked before and after to make sure they remain
correct/sensible:
- IMAGE_FSTYPES
- WKS_FILE_DEPENDS
- IMAGE_BOOT_FILES
- RK_CONSOLE_BAUD
- RK_CONSOLE_DEVICE
- RK_BOOT_DEVICE
- SERIAL_CONSOLES
- WICVARS
Build-tested for all currently-defined MACHINEs.
Boot-tested on the following boards to make sure they continue to boot to a
console correctly (core-image-base):
- tinker-board
- rock64
- rock-pi-4b
- rock-pi-e
- nanopi-m4-2gb
Signed-off-by: Trevor Woerner
---
conf/machine/firefly-rk3288.conf | 13 +--
conf/machine/include/nanopi-m4.inc | 11 -
conf/machine/include/rk3328.inc| 1 +
conf/machine/include/rk3399.inc| 1 +
conf/machine/include/rock-pi-4.inc | 11 -
conf/machine/include/rockchip-defaults.inc | 14 ---
conf/machine/include/rockchip-wic.inc | 27 ++
conf/machine/include/tinker.inc| 13 +--
conf/machine/rock-pi-e.conf| 10
conf/machine/rock64.conf | 11 -
conf/machine/vyasa-rk3288.conf | 13 +--
11 files changed, 32 insertions(+), 93 deletions(-)
create mode 100644 conf/machine/include/rockchip-wic.inc
diff --git a/conf/machine/firefly-rk3288.conf b/conf/machine/firefly-rk3288.conf
index 2a5f0ba..138e840 100644
--- a/conf/machine/firefly-rk3288.conf
+++ b/conf/machine/firefly-rk3288.conf
@@ -7,20 +7,9 @@
#http://www.t-firefly.com/en/
require conf/machine/include/rk3288.inc
+require conf/machine/include/rockchip-wic.inc
KERNEL_DEVICETREE = "rk3288-firefly.dtb"
UBOOT_MACHINE = "firefly-rk3288_defconfig"
WKS_FILE ?= "firefly-rk3288.wks"
-IMAGE_FSTYPES += "wic wic.bmap"
-
-WKS_FILE_DEPENDS ?= " \
-mtools-native \
-dosfstools-native \
-virtual/bootloader \
-virtual/kernel \
-"
-IMAGE_BOOT_FILES ?= "\
-${KERNEL_IMAGETYPE} \
-${KERNEL_DEVICETREE} \
-"
diff --git a/conf/machine/include/nanopi-m4.inc
b/conf/machine/include/nanopi-m4.inc
index 8a7c1d9..7ca91db 100644
--- a/conf/machine/include/nanopi-m4.inc
+++ b/conf/machine/include/nanopi-m4.inc
@@ -10,14 +10,3 @@ KERNEL_DEVICETREE = "rockchip/rk3399-nanopi-m4.dtb"
RK_BOOT_DEVICE = "mmcblk1"
WKS_FILE ?= "rock-pi-4.wks"
-IMAGE_FSTYPES += "wic wic.bmap"
-
-WKS_FILE_DEPENDS ?= " \
-mtools-native \
-dosfstools-native \
-virtual/bootloader \
-virtual/kernel \
-"
-IMAGE_BOOT_FILES ?= "\
-${KERNEL_IMAGETYPE} \
-"
diff --git a/conf/machine/include/rk3328.inc b/conf/machine/include/rk3328.inc
index 5b11868..b0cafb5 100644
--- a/conf/machine/include/rk3328.inc
+++ b/conf/machine/include/rk3328.inc
@@ -8,6 +8,7 @@ DEFAULTTUNE ?= "cortexa53-crypto"
require conf/machine/include/soc-family.inc
require conf/machine/include/tune-cortexa53.inc
require conf/machine/include/rockchip-defaults.inc
+require conf/machine/include/rockchip-wic.inc
KBUILD_DEFCONFIG ?= "defconfig"
KERNEL_CLASSES = "kernel-fitimage"
diff --git a/conf/machine/include/rk3399.inc b/conf/machine/include/rk3399.inc
index 9f9f474..79e83e2 100644
--- a/conf/machine/include/rk3399.inc
+++ b/conf/machine/include/rk3399.inc
@@ -8,6 +8,7 @@ DEFAULTTUNE ?= "cortexa72-cortexa53-crypto"
require conf/machine/include/soc-family.inc
require conf/machine/include/tune-cortexa72-cortexa53.inc
require conf/machine/include/rockchip-defaults.inc
+require conf/machine/include/rockchip-wic.inc
KBUILD_DEFCONFIG ?= "defconfig"
KERNEL_CLASSES = "kernel-fitimage"
diff --git a/conf/machine/include/rock-pi-4.inc
b/conf/machine/include/rock-pi-4.inc
index a3e60c7..92fc330 100644
--- a/conf/machine/include/rock-pi-4.inc
+++ b/conf/machine/include/rock-pi-4.inc
@@ -5,16 +5,5 @@ require conf/machine/include/rk3399.inc
RK_BOOT_DEVICE = "mmcblk1"
WKS_FILE ?= "rock-pi-4.wks"
-IMAGE_FSTYPES += "wic wic.bmap"
-
-WKS_FILE_DEPENDS ?= " \
-mtools-native \
-dosfstools-native \
-virtual/bootloader \
-virtual/kernel \
-"
-IMAGE_BOOT_FILES ?= "\
-${KERNEL_IMAGETYPE} \
-"
MACHINE_EXTRA_RRECOMMENDS += "kernel-modules"
diff --git a/conf/machine/include/rockchip-defaults.inc
b/conf/machine/include/rockchip-defaults.inc
index b0346c9..b41c523 100644
--- a/conf/machine/include/rockchip-defaults.inc
+++ b/conf/machine/include/rockchip-defaults.inc
@@ -23,17 +23,3 @@ XSERVER = " \
# misc
SERIAL_CONSOLES ?= "150;ttyS2"
IMAGE_FSTYPES += "ext4"
-
-# use the first-defined ; pair in SERIAL_CONSOLES
-# for the console parameter in the wks files
-RK_CONSOLE_BAUD ?= "${@d.getVar('SERIAL_CONSOLES').split(';')[0]}"
-RK_CONSOLE_DEVICE ?= "${@d.getVar('SERIAL_CONSOLES').split(';')[1].split()[0]}"
-
Re: [yocto] The do_populate_sdk is finishing OK even when there are errors present in the build
Hi Richard! Ok, I'll prepare a patch, do more tests on my side and if everything works I'll send the patch to the OE-core list. Is there any specific test, or just populate_sdk with core-image-base? Thanks! On Fri, Jun 25, 2021 at 8:48 AM Richard Purdie < richard.pur...@linuxfoundation.org> wrote: > On Thu, 2021-06-24 at 17:40 -0300, Fabio Berton wrote: > > Hi all! > > > > I'm running some test with do_populate_sdk task and I'm seeing this > > on the log: > > > > check_data_file_clashes: Package kmsxx-dbg wants to install file > /home/builder/build/tmp/work/foo-poky- > > > linux/core-image-minimal/1.0-r0/sdk/image/opt/bar/sysroots/aarch64-poky-linux/usr/bin/.debug/kmstest > > But that file is already provided by package * libdrm-dbg > > > > I also see this kind of message with other packages. > > > > Looking in the source code I found that the install_complementary > > function runs this [1] with attempt_only=True, and if attempt_only is > > true log above it's just a warning, as shown here [2]. > > > > This [3] comment says that "will only attempt to install these packages, > > if they don't exist then no error will occur." > > > > My question is how can I force an error and not just a warning when > > running do_populate_sdk? > > > > I understand that I can change [1] to run: > > > > self.install(install_pkgs) > > > > so, it'll use set attempt_only to False, that is the default, but I > > think this will break some use cases. > > > > What is the correct behaviour here, see the warning messages and fix > > the packages to avoid "file is already provided by package" messages, > > every time I create a SDK or change in some way to see an error message > > and stop SDK generation? > > > > What is the correct behavior here, inspect the warning messages, and > > fix the packages to avoid "file is already provided by package" messages, > > every time I create an SDK or change it in some way to see an error > > message and stop the SDK generation? > > It would probably be worth an experiment to see if we really do need the > attempt_only option set there any more. I'd hope it isn't needed now... > > It is probably worth testing a patch on the autobuilder, assuming your > local tests with that pass. We'd need to check the different package > backends are ok with that. > > Cheers, > > Richard > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#53977): https://lists.yoctoproject.org/g/yocto/message/53977 Mute This Topic: https://lists.yoctoproject.org/mt/83769900/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] The do_populate_sdk is finishing OK even when there are errors present in the build
On Thu, 2021-06-24 at 17:40 -0300, Fabio Berton wrote: > Hi all! > > I'm running some test with do_populate_sdk task and I'm seeing this > on the log: > > check_data_file_clashes: Package kmsxx-dbg wants to install file > /home/builder/build/tmp/work/foo-poky- > linux/core-image-minimal/1.0-r0/sdk/image/opt/bar/sysroots/aarch64-poky-linux/usr/bin/.debug/kmstest > But that file is already provided by package * libdrm-dbg > > I also see this kind of message with other packages. > > Looking in the source code I found that the install_complementary > function runs this [1] with attempt_only=True, and if attempt_only is > true log above it's just a warning, as shown here [2]. > > This [3] comment says that "will only attempt to install these packages, > if they don't exist then no error will occur." > > My question is how can I force an error and not just a warning when > running do_populate_sdk? > > I understand that I can change [1] to run: > > self.install(install_pkgs) > > so, it'll use set attempt_only to False, that is the default, but I > think this will break some use cases. > > What is the correct behaviour here, see the warning messages and fix > the packages to avoid "file is already provided by package" messages, > every time I create a SDK or change in some way to see an error message > and stop SDK generation? > > What is the correct behavior here, inspect the warning messages, and > fix the packages to avoid "file is already provided by package" messages, > every time I create an SDK or change it in some way to see an error > message and stop the SDK generation? It would probably be worth an experiment to see if we really do need the attempt_only option set there any more. I'd hope it isn't needed now... It is probably worth testing a patch on the autobuilder, assuming your local tests with that pass. We'd need to check the different package backends are ok with that. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#53976): https://lists.yoctoproject.org/g/yocto/message/53976 Mute This Topic: https://lists.yoctoproject.org/mt/83769900/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] what's the state of things with pushing the bounds on ASSUME_PROVIDED?
On Thu, 2021-06-24 at 07:50 -0400, Robert P. J. Day wrote: > i asked about this once upon a time, so i thought i'd follow up ... > given the fairly stable state of recent linux distros, is there any > standard for taking advantage of what *should* be robust native tools > rather than building them? (i'm ignoring taking advantage of sstate > and building SDKs and other clever speedups for now.) > > from scratch, i did a wind river (LINCD) build of > wrlinux-image-small (and i assume it would be much the same under > current oe-core), and i notice that numerous native tools were > compiled, including such standards as cmake, curl, elfutils ... the > list goes on and on. > > so other than the tools that are *required* to be installed, if i > mention that i am currently running ubuntu 20.04, is there any > indication as to which tools i'm relatively safe to take advantage > using ASSUME_PROVIDED and HOSTTOOLS? i realize that the versions built > will probably differ from the host versions, but it seems that if > there is an incompatibility, that would be fairly obvious in short > order. > > thoughts? Quite often things aren't as simple as they first seem: Elfutils has a history of interesting changes between versions so having our builds use a consistent version is good. Some recipes build libs as well as binaries, e.g. the compression tools. Its relatively easy to check a binary is present, it is harder to check the right -devel headers are present. That is a solvable problem but again, version consistency is good. If you require a HOSTTOOLS bin but our own lib, you can get version mismatches. We do patch some utilities for 'reasons' and having those patches missing can be a pain and cause weird errors. Reproducibility is also a concern, particularly if different versions of tools like flex/bison generated different code. I also wonder who is going to support testing all these different options and handle the resulting build failures and bugs being raised? This list isn't definitive. In summary, I see a lot of problems for what amounts to not much speed gain. Particularly when we have a mechanism like sstate available which allows binary reuse. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#53975): https://lists.yoctoproject.org/g/yocto/message/53975 Mute This Topic: https://lists.yoctoproject.org/mt/83758672/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] Hardknott (GCC10) Compiler Issues
> I have no idea if this is possible in the current YOCTO development stage: > GCCVERSION = "11.%" > To do the FF to GCC 11.> *WARNING: preferred version 11.% of gcc-runtime not available (for item libg2c)WARNING: versions of gcc-runtime available: 10.2.0* For hardknott. Guess, this answers my later question. Let us see about my very first question! BR, Zee ___ INCLUDED: WARNING: preferred version 11.% of gcc-runtime not available (for item libssp-dev) WARNING: versions of gcc-runtime available: 10.2.0 WARNING: preferred version 11.% of gcc-runtime not available (for item libg2c-dev) WARNING: versions of gcc-runtime available: 10.2.0 WARNING: preferred version 11.% of gcc-runtime not available (for item libssp) WARNING: versions of gcc-runtime available: 10.2.0 Build Configuration: BB_VERSION = "1.50.0" BUILD_SYS= "x86_64-linux" NATIVELSBSTRING = "fedora-33" TARGET_SYS = "arm-poky-linux-gnueabi" MACHINE = "beaglebone" DISTRO = "poky" DISTRO_VERSION = "3.3.1" TUNE_FEATURES= "arm vfp cortexa8 neon callconvention-hard" TARGET_FPU = "hard" meta meta-poky meta-yocto-bsp = "*hardknott:* 74dbb08c3709fec6563ee65a3661f66fdcbb3e2f" meta-jumpnow = "*hardknott* :ac90f018ebb9de8d6ac12f22368e004aa7be69a2" meta-bbb = "hardknott:d838aa54e3ed81d08597c08e112fc8966aaa501d" meta-oe meta-python meta-networking = "hardknott:aca88908fd329f5cef6f19995b072397fb2d8ec6" meta-qt5 = "upstream/hardknott:a00af3eae082b772469d9dd21b2371dd4d237684" meta-socketcan = "master:cefd86cd1def9ad2e63be527f8ce36a076d7e17c" NOTE: Fetching uninative binary shim http://downloads.yoctoproject.org/releases/uninative/3.2/x86_64-nativesdk-libc.tar.xz;sha256sum=3ee8c7d55e2d4c7ae3887cddb97219f97b94efddfeee2e24923c0cb0e8ce84c6 (will check PREMIRRORS first) Initialising tasks: 100% |###| Time: 0:00:11 Sstate summary: Wanted 1709 Local 0 Network 0 Missed 1709 Current 0 (0% match, 0% complete) NOTE: Executing Tasks On Fri, Jun 25, 2021 at 7:58 AM Zoran via lists.yoctoproject.org wrote: > An interesting issue, and I think I hit it as well (my best guess). > > Here is my issue: > https://github.com/mguentner/cannelloni/issues/35 > > > During the thud-to-hardknott upgrade process, we did nightly > > builds of the new hardknott based target image from our thud > > based SDK VM. I assumed that since GCC10 was being built > > as part of the build sysroot bootstrap process, we were getting > > a clean and consistent result irrespective of the underlying > > build server OS. > > Maybe you can try the following: in your local.conf to insert the > following line: > > GCCVERSION = "9.%" > > for hardknott release. > > I need to try this myself, I just used gcc as is (default one which > comes with the release, I guess 10). > > I have no idea if this is possible in the current YOCTO development stage: > > GCCVERSION = "11.%" > > To do the FF to GCC 11. > > Zee > ___ > > On Fri, Jun 25, 2021 at 6:48 AM Chuck Wolber > wrote: > > > > All, > > > > Please accept my apologies in advance for the detailed submission. I > think it is warranted in this > > case. > > > > There is something... "odd" about the GCC 10 compiler that is delivered > with Hardknott. I am still > > chasing it down, so I am not yet ready to declare a root cause or submit > a bug, but I am posting > > what I have now in case anyone has some insights to offer. > > > > For all I know it is something unusual that I am doing, but we have a > lot of history with our > > build/dev/release methods, so I would be surprised if that was actually > the case. I have also > > discussed aspects of this on IRC for the last few days, so some of this > may be familiar to some > > of you. > > > > Background: We maintain a virtual machine SDK for our developers that is > as close as possible to > > the actual embedded hardware environment that we target. The SDK image > is our baseline Linux > > OS plus lots of the expected dev and debugging tools. The image deployed > to our target devices is > > the baseline Linux OS plus the core application suite. It is also > important to note that we only > > support the x86_64 machine architecture in our target devices and > development workstations. > > > > We also spin up and spin down the SDK VM for our nightly builds. This > guarantees strict consistency > > and eliminates lots of variables when we are trying to troubleshoot > something hairy. > > > > We just upgraded from Thud to Hardknott. This means we built our new > Hardknott based SDK VM > > image from our Thud based SDK VM (GCC 8 / glibc 2.28). When we attempted > to build our target > > device image in the new Hardknott based SDK VM, we consistently got a > segfault when any build > > task involves bison issuing a warning of some sort. I traced this down > for a very long time and it >
