Openembedded Core Discussions
 help / color / mirror / Atom feed
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



  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