From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [217.70.183.196]) by mx.groups.io with SMTP id smtpd.web08.4755.1614438141929075518 for ; Sat, 27 Feb 2021 07:02:22 -0800 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: bootlin.com, ip: 217.70.183.196, mailfrom: alexandre.belloni@bootlin.com) X-Originating-IP: 90.65.108.55 Received: from localhost (lfbn-lyo-1-1676-55.w90-65.abo.wanadoo.fr [90.65.108.55]) (Authenticated sender: alexandre.belloni@bootlin.com) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 4ECADE0005; Sat, 27 Feb 2021 15:02:19 +0000 (UTC) Date: Sat, 27 Feb 2021 16:02:18 +0100 From: "Alexandre Belloni" To: yocto@mac.mcrowe.com Cc: openembedded-core@lists.openembedded.org, Mike Crowe , Khem Raj Subject: Re: [OE-core] [PATCH] gcc-sanitizers: Move content from gcclibdir into libdir Message-ID: References: <20210225173653.2408-1-mac@mcrowe.com> MIME-Version: 1.0 In-Reply-To: <20210225173653.2408-1-mac@mcrowe.com> Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hello, On 25/02/2021 17:36:53+0000, Mike Crowe via lists.openembedded.org wrote: > In e9e5744ba8b0d43c8b874d365f83071ce20bf0a1, Khem Raj wrote: > > OE does not use the traditional /usr/lib/gcc prefix to store > > gcc-runtime it basically is moved into libdir, however some newer > > files were installed by newer versions of gcc especially libgomp ( > > omp.h openacc.h ) into gcclibdir, so we have content in both > > directories, this confuses other tools which are trying to guess the > > gcc installation and its runtime location, since now we have two > > directories, the tools either choose one or other and we get > > inconsistent behavior, e.g. clang for aarch64 uses /usr/lib but same > > clang for riscv64 chose /usr/lib/gcc > > > This change ensures that OE ends up with single valid location for gcc > > runtime files > > I think that the same thing needs to happen in gcc-sanitizers.inc, > otherwise I get errors like: > > | .../recipe-sysroot/usr/include/gpg-error-64.h:884:11: fatal error: sanitizer/lsan_interface.h: No such file or directory > > when attempting to compile with sanitizers enabled. > > Signed-off-by: Mike Crowe > Cc: Khem Raj > --- > meta/recipes-devtools/gcc/gcc-sanitizers.inc | 5 +++++ > 1 file changed, 5 insertions(+) > > diff --git a/meta/recipes-devtools/gcc/gcc-sanitizers.inc b/meta/recipes-devtools/gcc/gcc-sanitizers.inc > index 668e14a59f..67b755edf8 100644 > --- a/meta/recipes-devtools/gcc/gcc-sanitizers.inc > +++ b/meta/recipes-devtools/gcc/gcc-sanitizers.inc > @@ -35,6 +35,11 @@ do_compile () { > do_install () { > cd ${B}/${TARGET_SYS}/libsanitizer/ > oe_runmake 'DESTDIR=${D}' MULTIBUILDTOP=${B}/${TARGET_SYS}/libsanitizer/ install > + if [ -d ${D}${libdir}/gcc/${TARGET_SYS}/${BINV}/include ]; then > + install -d ${D}${libdir}/${TARGET_SYS}/${BINV}/include > + mv ${D}${libdir}/gcc/${TARGET_SYS}/${BINV}/include/* ${D}${libdir}/${TARGET_SYS}/${BINV}/include > + rmdir --ignore-fail-on-non-empty -p ${D}${libdir}/gcc/${TARGET_SYS}/${BINV}/include > + fi > if [ -d ${D}${infodir} ]; then > rmdir --ignore-fail-on-non-empty -p ${D}${infodir} > fi This seems to result in the following erro on the autobuilders: ERROR: gcc-sanitizers-10.2.0-r0 do_package: QA Issue: gcc-sanitizers: Files/directories were installed but not shipped in any package: /usr/lib/i686-poky-linux /usr/lib/i686-poky-linux/10.2.0 /usr/lib/i686-poky-linux/10.2.0/include /usr/lib/i686-poky-linux/10.2.0/include/sanitizer /usr/lib/i686-poky-linux/10.2.0/include/sanitizer/common_interface_defs.h /usr/lib/i686-poky-linux/10.2.0/include/sanitizer/lsan_interface.h /usr/lib/i686-poky-linux/10.2.0/include/sanitizer/asan_interface.h /usr/lib/i686-poky-linux/10.2.0/include/sanitizer/tsan_interface.h Please set FILES such that these items are packaged. Alternatively if they are unneeded, avoid installing them or delete them within do_install. gcc-sanitizers: 8 installed and not shipped files. [installed-vs-shipped] ERROR: gcc-sanitizers-10.2.0-r0 do_package: Fatal QA errors found, failing task. It seems to be an easy one to fix. Regards, -- Alexandre Belloni, co-owner and COO, Bootlin Embedded Linux and Kernel engineering https://bootlin.com