From: "Mike Crowe" <yocto@mac.mcrowe.com>
To: openembedded-core@lists.openembedded.org
Cc: Mike Crowe <mac@mcrowe.com>, Khem Raj <raj.khem@gmail.com>
Subject: [PATCH] gcc-sanitizers: Move content from gcclibdir into libdir
Date: Thu, 25 Feb 2021 17:36:53 +0000 [thread overview]
Message-ID: <20210225173653.2408-1-mac@mcrowe.com> (raw)
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 <mac@mcrowe.com>
Cc: Khem Raj <raj.khem@gmail.com>
---
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
--
2.20.1
next reply other threads:[~2021-02-25 17:37 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-25 17:36 Mike Crowe [this message]
2021-02-25 18:27 ` [PATCH] gcc-sanitizers: Move content from gcclibdir into libdir Khem Raj
2021-02-27 15:02 ` [OE-core] " Alexandre Belloni
2021-02-27 16:30 ` Khem Raj
2021-02-28 12:25 ` Mike Crowe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210225173653.2408-1-mac@mcrowe.com \
--to=yocto@mac.mcrowe.com \
--cc=mac@mcrowe.com \
--cc=openembedded-core@lists.openembedded.org \
--cc=raj.khem@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.