From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Khem Raj <raj.khem@gmail.com>, Patrick Ohly <patrick.ohly@intel.com>
Cc: OpenEmbedded <openembedded-core@lists.openembedded.org>
Subject: Re: go-cross: incorrect dependency on tune-specific libgcc
Date: Tue, 11 Apr 2017 17:57:04 +0100 [thread overview]
Message-ID: <1491929824.12091.28.camel@linuxfoundation.org> (raw)
In-Reply-To: <CAMKF1srOa1mWXXRvF9_EXrUFiy43_K4kAC4i9aYdpsm2hTJQNw@mail.gmail.com>
On Tue, 2017-04-11 at 09:39 -0700, Khem Raj wrote:
> On Tue, Apr 11, 2017 at 9:34 AM, Patrick Ohly <patrick.ohly@intel.com
> > wrote:
> >
> > On Mon, 2017-04-10 at 14:49 +0200, Patrick Ohly wrote:
> > >
> > > Hello!
> > >
> > > I'm currently extending the yocto-compat-layer.py so that it can
> > > detect
> > > invalid signature changes when changing MACHINE. go-cross-x86_64
> > > shows
> > > up as broken when comparing signatures for MACHINE=intel-corei7-
> > > 64 and
> > > MACHINE=qemux86-64.
> > >
> > > Both machines share the same go-cross-x86_64, but that DEPENDS on
> > > libgcc:
> > >
> > > meta/recipes-devtools/go/go.inc:# libgcc is required for the
> > > target specific libraries to build properly
> > > meta/recipes-devtools/go/go.inc:DEPENDS += "go-bootstrap-native
> > > libgcc"
> > >
> > > And libgcc itself depends on the tune flags for the target
> > > architecture
> > > and thus is different for these two machines:
> > >
> > > $ bitbake-diffsigs -t go-cross-x86_64 do_prepare_recipe_sysroot
> > > -s 563f419e3854c2351e2cbbf33a9025f6
> > > 64e378fd9853a6cd6a4e7f684f52d2fc
> > > Hash for dependent task gcc/libgcc_6.3.bb.do_populate_sysroot
> > > changed from afb6b55c0e2b7d2e816b3d2d214a7326 to
> > > 208fac5ae428b07a4aa491b130879e4a
> > > Hash for dependent task gcc/libgcc_6.3.bb.do_multilib_install
> > > changed from 596e1612d7b84b7a9c1b409ee78cca89 to
> > > d41e2e835d0abe7646e53e3d63ce00cd
> > > Hash for dependent task gcc/libgcc_6.3.bb.do_install changed
> > > from 9ca4126c69fcceb410253a0603c3d76b to
> > > cb0c49687a91ea17f1027c6394baacab
> > > Hash for dependent task gcc/libgcc_6.3.bb.do_compile
> > > changed from ab80902424c73af49257cc3f6fe049aa to
> > > 436f978a703476968bd5ae1c1915ee5a
> > > Hash for dependent task gcc/libgcc_6.3.bb.do_configure
> > > changed from eb0c36d87f32ce1ceb7d1e42609578fb to
> > > f62c98806faf3a28c2144919b89d3460
> > > Hash for dependent task
> > > gcc/libgcc_6.3.bb.do_prepare_recipe_sysroot changed from
> > > b037b950e346bef71a4f8fd2c6a2195c to
> > > d4564b5730941279392932e3c670a5a5
> > > Hash for dependent task gcc/libgcc_6.3.bb.do_fetch
> > > changed from e64cd9e029ed63ba3a09e5fe085b7057 to
> > > ea4d3f9d10544219ceb8591d5a5a4041
> > > basehash changed from
> > > 8744593af2eddb60244788f2b9476e2d to
> > > dabeb22478ef501e35311af75119a2cf
> > > Variable TUNE_CCARGS value changed:
> > > " -m64 [--march=corei7 -mtune=corei7-] {+-
> > > march=core2 -mtune=core2 -msse3+} -mfpmath=sse [--msse4.2-]"
> > >
> > > Does this fix look correct? It turns go-cross into a package that
> > > is
> > > specific to the tune flags for the target.
> > [...]
> >
> > >
> > > The alternative would be to drop the libgcc dependency, but I
> > > have no
> > > idea whether that would work at all.
> > Besides Bruce who pointed out the implications on recipes depending
> > on
> > go-cross-${TARGET_ARCH}, Richard also had concerns about making go-
> > cross
> > tune-specific, so I ended up testing the libgcc removal approach.
> > It
> > happened to build okay, so the patch that I ended up proposing (see
> > "go-cross: avoid libgcc dependency") just removes libgcc from
> > DEPENDS
> > for go-cross.
> >
> > I need to revise the method how its done (i.e. not with
> > DEPENDS_remove),
> > but besides that, can anyone explain whether such a change might
> > hit
> > some problems somewhere? Khem?
> >
> I think TUNE_PKGARCH is the granularity it needs for setting GOARM
> anyway. It should be fine to change it.
Once we go down the TUNE_PKGARCH route we probably won't get back. I'm
reluctant to give up on this quite so easily since having common tools
make a lot of sense from a build time perspective (and we already have
fun with testing and the time it takes).
We could make arm append a v7 to PN in the v7 case and only have two go
compilers on arm to address the GOARM issue...
Cheers,
Richard
next prev parent reply other threads:[~2017-04-11 17:48 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-10 12:49 go-cross: incorrect dependency on tune-specific libgcc Patrick Ohly
2017-04-10 12:59 ` Bruce Ashfield
2017-04-10 13:09 ` Patrick Ohly
2017-04-10 13:16 ` Bruce Ashfield
2017-04-10 14:44 ` Patrick Ohly
2017-04-11 16:34 ` Patrick Ohly
2017-04-11 16:39 ` Khem Raj
2017-04-11 16:52 ` Patrick Ohly
2017-04-11 17:01 ` Khem Raj
2017-04-11 18:26 ` Patrick Ohly
2017-04-11 16:57 ` Richard Purdie [this message]
2017-04-11 18:22 ` Khem Raj
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=1491929824.12091.28.camel@linuxfoundation.org \
--to=richard.purdie@linuxfoundation.org \
--cc=openembedded-core@lists.openembedded.org \
--cc=patrick.ohly@intel.com \
--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.