From: richard.purdie@linuxfoundation.org
To: Bruce Ashfield <bruce.ashfield@windriver.com>
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [PATCH v2] kernel-devsrc: restructure for out of tree (and on target) module builds
Date: Thu, 26 Jul 2018 15:17:56 +0100 [thread overview]
Message-ID: <4bdbc774f6b6fe04fc4301980729c890a0502c8d.camel@linuxfoundation.org> (raw)
In-Reply-To: <1cc72609-d849-f8a3-6524-1f7d9ad214c3@windriver.com>
On Thu, 2018-07-26 at 10:04 -0400, Bruce Ashfield wrote:
> On 2018-07-10 6:21 AM, Richard Purdie wrote:
> > and also a failure in one of the multilib builds, probably from
> > different dependencies pulled in by kernel-devsrc:
> >
> > https://autobuilder.yocto.io/builders/nightly-multilib/builds/1139/
> > steps/BuildImages_4/logs/stdio
> >
> > Error: Transaction check error:
> > file /usr/bin/libtool from install of libtool-2.4.6-r0.0.i586
> > conflicts with file from package lib64-libtool-2.4.6-r0.0.x86_64
> > file /usr/bin/libtoolize from install of libtool-2.4.6-r0.0.i586
> > conflicts with file from package lib64-libtool-2.4.6-r0.0.x86_64
> >
>
> And that leaves this error.
>
> I've not been able to reproduce it, and I've been looking at the
> elfutils RDEPENDS that is part of kernel devsrc, since that is what
> pulls in libtool as a DEPENDS.
>
> I'm not seeing any difference in the way that it is pulled in, versus
> the other uses.
>
> In particular, perf also has elfutils as a REDEPENDS, but yet it
> builds
> in the same configuration. Can you spot the difference in how it is
> used ?
>
> elfutils is potentially required at tools build time, hence why it is
> a RDEPENDS in devsrc, but a DEPENDS in the main linux-yocto recipes.
> If there's another way to express this, let me know and I can switch
> to that.
>
> And finally, I did build the old reproducing configuration for
> multlib that you mentioned before .. can you point me at this config,
> so I can try again ?
This is a timely reminder that I've been meaning to look at this. I
think the config is:
t
MACHINE=qemux86
require conf/multilib.conf
MULTILIBS = "multilib:lib64"
DEFAULTTUNE_virtclass-multilib-lib64 = "x86-64"
then bitbake lib64-core-image-sato-sdk
which seems like an odd mix of 64bit with a 32 bit kernel but is
nonetheless what it appears to be building. I suspect it will fail the
same way with the x86-64 machine too though.
I have a build running now to check if I can replicate and perhaps dig
into it further.
Cheers,
Richard
next prev parent reply other threads:[~2018-07-26 14:17 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-09 15:53 [PATCH v2] kernel-devsrc: restructure for out of tree (and on target) module builds Bruce Ashfield
2018-07-10 10:21 ` Richard Purdie
2018-07-10 13:09 ` Bruce Ashfield
2018-07-10 16:38 ` Bruce Ashfield
2018-07-10 21:41 ` Richard Purdie
2018-07-11 2:34 ` Bruce Ashfield
2018-07-12 13:49 ` Bruce Ashfield
2018-07-12 13:53 ` Richard Purdie
2018-07-12 13:55 ` Bruce Ashfield
2018-07-12 17:02 ` Khem Raj
2018-07-12 17:07 ` Bruce Ashfield
2018-07-12 17:22 ` Khem Raj
2018-07-12 17:26 ` Bruce Ashfield
2018-07-26 14:04 ` Bruce Ashfield
2018-07-26 14:17 ` richard.purdie [this message]
2018-07-26 17:01 ` Richard Purdie
2018-07-30 22:26 ` richard.purdie
2018-07-31 1:07 ` Bruce Ashfield
-- strict thread matches above, loose matches on Subject: below --
2018-02-28 19:20 Bruce Ashfield
2018-02-28 21:10 ` Mark Hatle
2018-02-28 21:12 ` Bruce Ashfield
2018-03-01 8:28 ` Maxin B. John
2018-03-01 9:37 ` Burton, Ross
2018-03-01 10:58 ` Maxin B. John
2018-03-01 12:58 ` Bruce Ashfield
2018-03-01 13:59 ` Bruce Ashfield
2018-03-01 14:22 ` Burton, Ross
2018-03-01 14:45 ` Bruce Ashfield
2018-03-01 14:57 ` Burton, Ross
2018-03-02 14:23 ` Bruce Ashfield
2018-03-02 14:26 ` Burton, Ross
2018-03-02 15:20 ` Khem Raj
2018-03-02 18:16 ` Khem Raj
2018-03-02 19:29 ` Bruce Ashfield
2018-03-02 23:14 ` Burton, Ross
2018-03-01 12:57 ` Bruce Ashfield
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=4bdbc774f6b6fe04fc4301980729c890a0502c8d.camel@linuxfoundation.org \
--to=richard.purdie@linuxfoundation.org \
--cc=bruce.ashfield@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox