From: Mike Crowe <mac@mcrowe.com>
To: ChenQi <Qi.Chen@windriver.com>, openembedded-core@lists.openembedded.org
Subject: Re: [PATCH] multilib.conf: Ensure that RECIPE_SYSROOT is unchanged for native
Date: Wed, 18 Dec 2019 11:43:30 +0000 [thread overview]
Message-ID: <20191218114330.GA12175@mcrowe.com> (raw)
In-Reply-To: <983ec762-e2ad-4127-00c4-dec513486695@windriver.com>
On Wednesday 18 December 2019 at 09:19:20 +0800, ChenQi wrote:
> On 12/17/2019 09:55 PM, Mike Crowe wrote:
> > On Tuesday 17 December 2019 at 16:56:11 +0800, ChenQi wrote:
> > > On 12/17/2019 04:02 PM, Mike Crowe via Openembedded-core wrote:
> > > > Ensure that RECIPE_SYSROOT is the same for -native recipes whether
> > > > multilib.conf is included or not.
> > > >
> > > > Without this change task signatures for -native recipes change when
> > > > switching between MACHINEs that require multilib.conf and those that
> > > > don't.
> > > >
> > > > This fix was one of the ones suggested by Khem Raj in
> > > > http://lists.openembedded.org/pipermail/openembedded-core/2019-December/290303.html
> > > >
> > > > Add test_sstate_multilib_or_not_native_samesigs test case to
> > > > sstatetests.py to ensure that this stays fixed.
> > > >
> > > > Signed-off-by: Mike Crowe <mac@mcrowe.com>
> > > > ---
> > > > meta/conf/multilib.conf | 1 +
> > > > meta/lib/oeqa/selftest/cases/sstatetests.py | 40 +++++++++++++++++++++
> > > > 2 files changed, 41 insertions(+)
> > > >
> > > > diff --git a/meta/conf/multilib.conf b/meta/conf/multilib.conf
> > > > index cfed3fbbd0..58f2ac5c86 100644
> > > > --- a/meta/conf/multilib.conf
> > > > +++ b/meta/conf/multilib.conf
> > > > @@ -9,6 +9,7 @@ MULTILIBS ??= "multilib:lib32"
> > > > STAGING_DIR_HOST = "${WORKDIR}/${MLPREFIX}recipe-sysroot"
> > > > STAGING_DIR_TARGET = "${WORKDIR}/${MLPREFIX}recipe-sysroot"
> > > > RECIPE_SYSROOT = "${WORKDIR}/${MLPREFIX}recipe-sysroot"
> > > > +RECIPE_SYSROOT_class-native = "${WORKDIR}/recipe-sysroot"
> > > How about just removing MLPREFIX?
> >
> > I'm afraid that I don't understand what you are suggesting. The above
> > change does remove MLPREFIX for -native only.
>
> I mean removing all these MLPREFIX, so that STAGING_DIR_HOST,
> STAGING_DIR_TARGET and RECIPE_SYSROOT will all be
> ${WORKDIR}/recipe-sysroot.
The prefix is necessary for RECIPE_SYSROOT because without it a single
recipe can't depend on multiple multilib variants of the same recipe. We do
this because our bootloader requires both a 32-bit and a 64-bit compiler.
When I changed RECIPE_SYSROOT to always be "${WORKDIR}/recipe-sysroot" I
get failures like:
do_prepare_recipe_sysroot: The file /usr/include/mtd/mtd-user.h is installed by both linux-libc-headers and lib32-linux-libc-headers, aborting
Thanks.
Mike.
prev parent reply other threads:[~2019-12-18 11:43 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-17 8:02 [PATCH] multilib.conf: Ensure that RECIPE_SYSROOT is unchanged for native Mike Crowe
2019-12-17 8:56 ` ChenQi
2019-12-17 13:55 ` Mike Crowe
2019-12-18 1:19 ` ChenQi
2019-12-18 11:43 ` Mike Crowe [this message]
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=20191218114330.GA12175@mcrowe.com \
--to=mac@mcrowe.com \
--cc=Qi.Chen@windriver.com \
--cc=openembedded-core@lists.openembedded.org \
/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.