On Thursday, March 14, 2019 2:44:35 PM EDT Christopher Larson wrote:
> Good to know, thanks. Possibly something to improve in bitbake at some
> point in the future.
This is what I am preparing to send out
---
GOARM[export] = "0"
GOARM_arm_class-target = "${TARGET_GOARM}"
GOARM_arm_class-target[export] = "1"
---
This should address Mark Hatle's concerns about GOARM being undefined/have
deterministic behavior. For non-'arm' the export simply won't be present so it
doesn't matter what GOARM is, for 'arm' we get what we want. And I get what I
was aiming for, no environment pollution in run.do_compile and friends for
non-'arm'.
I know it isn't really used elsewhere but I don't believe I am making any
assumptions or using things in a way they shouldn't be used. At any rate I
will send this out in 20 minutes or so and we'll see how it stands up.
MarkA
>
> On Thu, Mar 14, 2019 at 11:32 AM Mark Asselstine <
>
> mark.asselst...@windriver.com> wrote:
> > On Wednesday, March 13, 2019 3:40:18 PM EDT Christopher Larson wrote:
> > > How would bitbake respond to an ‘export’ line with the empty string?
> > > I.e.
> > > can you do an actual conditional export the way we do conditional
> >
> > inherits,
> >
> > > so it still is only exported for arm, even if the value is set to the
> >
> > empty
> >
> > > string for others?
> >
> > Unfortunately no. It is a parsing error.
> >
> > I am working on alternatives and will hopefully have something out
> > shortly.
> >
> > MarkA
> >
> > > On Wed, Mar 13, 2019 at 10:57 AM Mark Asselstine <
> > >
> > > mark.asselst...@windriver.com> wrote:
> > > > When building GO packages for ARM (v5, v6, v7) it is expected that the
> > > > GOARM env variable is set during the build. Not having GOARM exported
> > > > will result in GO binaries which can't be executed on the target
> > > > (terminate with segfault). Per https://github.com/golang/go/wiki/GoArm
> > > >
> > > > We already have the logic in goarch.bbclass to determine the correct
> > > > value of GOARM (see GOARM_TARGET), but currently this is only used to
> > > > build go itself (go-cross_1.*.bb requires go-cross.inc --> export
> > > > GOARM = "${TARGET_GOARM}").
> > > >
> > > > Here we export GOARM but we do it such that it is only exported if we
> > > > are building for 'arm' and only when recipes requiring/inheriting
> > > > go.bbclass are be used to build for the target.
> > > >
> > > > Signed-off-by: Mark Asselstine <mark.asselst...@windriver.com>
> > > > ---
> > > >
> > > > Richard,
> > > >
> > > > MarkH and I were debating this one some. He was suggesting I add
> > > > 'GOARM ?= ""' so as not to leave things undefined for non-arm target
> > > > builds. I however, like the behavior of this as submitted here as
> > > > non-arm target builds don't get polluted with a useless export in
> > > > their do_compile scripts and such. The question is as presented here
> > > > is the behavior deterministic?
> > > >
> > > >
> > > > meta/classes/go.bbclass | 3 +++
> > > >
> > > > 1 file changed, 3 insertions(+)
> > > >
> > > > diff --git a/meta/classes/go.bbclass b/meta/classes/go.bbclass
> > > > index af331f8..72e2c29 100644
> > > > --- a/meta/classes/go.bbclass
> > > > +++ b/meta/classes/go.bbclass
> > > > @@ -8,6 +8,9 @@ GOROOT = "${STAGING_LIBDIR}/go"
> > > >
> > > > export GOROOT
> > > > export GOROOT_FINAL = "${libdir}/go"
> > > >
> > > > +GOARM_arm_class-target = "${TARGET_GOARM}"
> > > > +export GOARM
> > > > +
> > > >
> > > > DEPENDS_GOLANG_class-target = "virtual/${TUNE_PKGARCH}-go
> > > >
> > > > virtual/${TARGET_PREFIX}go-runtime"
> > > >
> > > > DEPENDS_GOLANG_class-native = "go-native"
> > > > DEPENDS_GOLANG_class-nativesdk = "virtual/${TARGET_PREFIX}go-crosssdk
> > > >
> > > > virtual/${TARGET_PREFIX}go-runtime"
> > > > --
> > > > 2.7.4
> > > >
> > > > --
> > > > _______________________________________________
> > > > Openembedded-core mailing list
> > > > Openembedded-core@lists.openembedded.org
> > > > http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
