All of lore.kernel.org
 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 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.