* [PATCH 1/2] buildtools-tarball.bb: 32bit tools need pseudo 32bit library
@ 2015-12-03 23:09 Juro Bystricky
2015-12-03 23:09 ` [PATCH 2/2] oe-buildenv-internal: preserve existing BB_ENV_EXTRAWHITE Juro Bystricky
0 siblings, 1 reply; 4+ messages in thread
From: Juro Bystricky @ 2015-12-03 23:09 UTC (permalink / raw)
To: openembedded-core; +Cc: jurobystricky
"pseudo" does not build 32 bit library by default on 64 bit host, but the
32 bit library is needed when using 32 bit development tools (buildtools-tarball)
running on a 64 bit host. Building of the library can be forced if the
environment variable NO32LIBS is set to "0".
Hence for 32 bit buildtools we export the environment variable NO32LIBS="0"
and NO32LIBS is also added into BB_ENV_EXTRAWHITE (if not already there).
[YOCTO#8581]
Signed-off-by: Juro Bystricky <juro.bystricky@intel.com>
---
meta/recipes-core/meta/buildtools-tarball.bb | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/meta/recipes-core/meta/buildtools-tarball.bb b/meta/recipes-core/meta/buildtools-tarball.bb
index 840434c..8ad4e91 100644
--- a/meta/recipes-core/meta/buildtools-tarball.bb
+++ b/meta/recipes-core/meta/buildtools-tarball.bb
@@ -56,4 +56,10 @@ create_sdk_files_append () {
toolchain_create_sdk_version ${SDK_OUTPUT}/${SDKPATH}/version-${SDK_SYS}
echo 'export GIT_SSL_CAINFO="${SDKPATHNATIVE}${sysconfdir}/ssl/certs/ca-certificates.crt"' >>$script
+
+ if [ ${SDKMACHINE} = "i686" ]; then
+ echo 'export NO32LIBS="0"' >>$script
+ echo 'echo "$BB_ENV_EXTRAWHITE" | grep -q "NO32LIBS"' >>$script
+ echo '[ $? != 0 ] && export BB_ENV_EXTRAWHITE="NO32LIBS $BB_ENV_EXTRAWHITE"' >>$script
+ fi
}
--
1.9.1
^ permalink raw reply related [flat|nested] 4+ messages in thread
* [PATCH 2/2] oe-buildenv-internal: preserve existing BB_ENV_EXTRAWHITE
2015-12-03 23:09 [PATCH 1/2] buildtools-tarball.bb: 32bit tools need pseudo 32bit library Juro Bystricky
@ 2015-12-03 23:09 ` Juro Bystricky
2015-12-14 23:47 ` Andre McCurdy
0 siblings, 1 reply; 4+ messages in thread
From: Juro Bystricky @ 2015-12-03 23:09 UTC (permalink / raw)
To: openembedded-core; +Cc: jurobystricky
According to the BitBake User Manual the environment variable BB_ENV_EXTRAWHITE
specifies an additional set of variables to allow through (whitelist) from the
external environment into BitBake's datastore. However, running:
$ source oe-init-build-env build-name
will overwrite any pre-existing BB_ENV_EXTRAWHITE variables.
This patch modifies this behaviour: all oe-build-internal BB_ENV_EXTRAWHITE
variables are appended to any potentially already existing BB_ENV_EXTRAWHITE
variables. (The variables are only appended if not already in BB_ENV_EXTRAWHITE)
Signed-off-by: Juro Bystricky <juro.bystricky@intel.com>
---
scripts/oe-buildenv-internal | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/scripts/oe-buildenv-internal b/scripts/oe-buildenv-internal
index 9ed2721..51e449a 100755
--- a/scripts/oe-buildenv-internal
+++ b/scripts/oe-buildenv-internal
@@ -102,8 +102,12 @@ unset BITBAKEDIR NEWPATHS
# Used by the runqemu script
export BUILDDIR
export PATH
-export BB_ENV_EXTRAWHITE="MACHINE DISTRO TCMODE TCLIBC HTTP_PROXY http_proxy \
+
+BB_ENV_EXTRAWHITE_OE="MACHINE DISTRO TCMODE TCLIBC HTTP_PROXY http_proxy \
HTTPS_PROXY https_proxy FTP_PROXY ftp_proxy FTPS_PROXY ftps_proxy ALL_PROXY \
all_proxy NO_PROXY no_proxy SSH_AGENT_PID SSH_AUTH_SOCK BB_SRCREV_POLICY \
SDKMACHINE BB_NUMBER_THREADS BB_NO_NETWORK PARALLEL_MAKE GIT_PROXY_COMMAND \
SOCKS5_PASSWD SOCKS5_USER SCREENDIR STAMPS_DIR"
+
+echo "$BB_ENV_EXTRAWHITE" | grep -q "${BB_ENV_EXTRAWHITE_OE}"
+[ $? != 0 ] && export BB_ENV_EXTRAWHITE="${BB_ENV_EXTRAWHITE_OE} $BB_ENV_EXTRAWHITE"
--
1.9.1
^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: [PATCH 2/2] oe-buildenv-internal: preserve existing BB_ENV_EXTRAWHITE
2015-12-03 23:09 ` [PATCH 2/2] oe-buildenv-internal: preserve existing BB_ENV_EXTRAWHITE Juro Bystricky
@ 2015-12-14 23:47 ` Andre McCurdy
2015-12-21 17:00 ` Bystricky, Juro
0 siblings, 1 reply; 4+ messages in thread
From: Andre McCurdy @ 2015-12-14 23:47 UTC (permalink / raw)
To: Juro Bystricky; +Cc: jurobystricky, OE Core mailing list
On Thu, Dec 3, 2015 at 3:09 PM, Juro Bystricky <juro.bystricky@intel.com> wrote:
> According to the BitBake User Manual the environment variable BB_ENV_EXTRAWHITE
> specifies an additional set of variables to allow through (whitelist) from the
> external environment into BitBake's datastore. However, running:
>
> $ source oe-init-build-env build-name
>
> will overwrite any pre-existing BB_ENV_EXTRAWHITE variables.
> This patch modifies this behaviour: all oe-build-internal BB_ENV_EXTRAWHITE
> variables are appended to any potentially already existing BB_ENV_EXTRAWHITE
> variables. (The variables are only appended if not already in BB_ENV_EXTRAWHITE)
>
> Signed-off-by: Juro Bystricky <juro.bystricky@intel.com>
> ---
> scripts/oe-buildenv-internal | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/scripts/oe-buildenv-internal b/scripts/oe-buildenv-internal
> index 9ed2721..51e449a 100755
> --- a/scripts/oe-buildenv-internal
> +++ b/scripts/oe-buildenv-internal
> @@ -102,8 +102,12 @@ unset BITBAKEDIR NEWPATHS
> # Used by the runqemu script
> export BUILDDIR
> export PATH
> -export BB_ENV_EXTRAWHITE="MACHINE DISTRO TCMODE TCLIBC HTTP_PROXY http_proxy \
> +
> +BB_ENV_EXTRAWHITE_OE="MACHINE DISTRO TCMODE TCLIBC HTTP_PROXY http_proxy \
> HTTPS_PROXY https_proxy FTP_PROXY ftp_proxy FTPS_PROXY ftps_proxy ALL_PROXY \
> all_proxy NO_PROXY no_proxy SSH_AGENT_PID SSH_AUTH_SOCK BB_SRCREV_POLICY \
> SDKMACHINE BB_NUMBER_THREADS BB_NO_NETWORK PARALLEL_MAKE GIT_PROXY_COMMAND \
> SOCKS5_PASSWD SOCKS5_USER SCREENDIR STAMPS_DIR"
> +
> +echo "$BB_ENV_EXTRAWHITE" | grep -q "${BB_ENV_EXTRAWHITE_OE}"
> +[ $? != 0 ] && export BB_ENV_EXTRAWHITE="${BB_ENV_EXTRAWHITE_OE} $BB_ENV_EXTRAWHITE"
If ${BB_ENV_EXTRAWHITE_OE} is found in ${BB_ENV_EXTRAWHITE} (e.g. if
oe-init-build-env is re-run from a shell where it has already been run
before), then this change cause oe-buildenv-internal to exit with a
non-zero status, which will prevent oe-init-build-env from calling
oe-setup-builddir or cd'ing to ${BUILDDIR}. Is that really the
intention? It breaks my typical work flow...
> --
> 1.9.1
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH 2/2] oe-buildenv-internal: preserve existing BB_ENV_EXTRAWHITE
2015-12-14 23:47 ` Andre McCurdy
@ 2015-12-21 17:00 ` Bystricky, Juro
0 siblings, 0 replies; 4+ messages in thread
From: Bystricky, Juro @ 2015-12-21 17:00 UTC (permalink / raw)
To: Andre McCurdy; +Cc: jurobystricky, OE Core mailing list
Thanks, it is a legitimate bug, certainly not intended.
I already posted a patch to the mailing list last week.
> -----Original Message-----
> From: Andre McCurdy [mailto:armccurdy@gmail.com]
> Sent: Monday, December 14, 2015 3:47 PM
> To: Bystricky, Juro
> Cc: OE Core mailing list; jurobystricky@hotmail.com
> Subject: Re: [OE-core] [PATCH 2/2] oe-buildenv-internal: preserve existing
> BB_ENV_EXTRAWHITE
>
> On Thu, Dec 3, 2015 at 3:09 PM, Juro Bystricky <juro.bystricky@intel.com>
> wrote:
> > According to the BitBake User Manual the environment variable
> > BB_ENV_EXTRAWHITE specifies an additional set of variables to allow
> > through (whitelist) from the external environment into BitBake's datastore.
> However, running:
> >
> > $ source oe-init-build-env build-name
> >
> > will overwrite any pre-existing BB_ENV_EXTRAWHITE variables.
> > This patch modifies this behaviour: all oe-build-internal
> > BB_ENV_EXTRAWHITE variables are appended to any potentially already
> > existing BB_ENV_EXTRAWHITE variables. (The variables are only appended
> > if not already in BB_ENV_EXTRAWHITE)
> >
> > Signed-off-by: Juro Bystricky <juro.bystricky@intel.com>
> > ---
> > scripts/oe-buildenv-internal | 6 +++++-
> > 1 file changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/scripts/oe-buildenv-internal
> > b/scripts/oe-buildenv-internal index 9ed2721..51e449a 100755
> > --- a/scripts/oe-buildenv-internal
> > +++ b/scripts/oe-buildenv-internal
> > @@ -102,8 +102,12 @@ unset BITBAKEDIR NEWPATHS # Used by the
> runqemu
> > script export BUILDDIR export PATH -export
> > BB_ENV_EXTRAWHITE="MACHINE DISTRO TCMODE TCLIBC HTTP_PROXY
> http_proxy
> > \
> > +
> > +BB_ENV_EXTRAWHITE_OE="MACHINE DISTRO TCMODE TCLIBC
> HTTP_PROXY
> > +http_proxy \
> > HTTPS_PROXY https_proxy FTP_PROXY ftp_proxy FTPS_PROXY ftps_proxy
> > ALL_PROXY \ all_proxy NO_PROXY no_proxy SSH_AGENT_PID
> SSH_AUTH_SOCK
> > BB_SRCREV_POLICY \ SDKMACHINE BB_NUMBER_THREADS
> BB_NO_NETWORK
> > PARALLEL_MAKE GIT_PROXY_COMMAND \ SOCKS5_PASSWD
> SOCKS5_USER SCREENDIR STAMPS_DIR"
> > +
> > +echo "$BB_ENV_EXTRAWHITE" | grep -q "${BB_ENV_EXTRAWHITE_OE}"
> > +[ $? != 0 ] && export
> BB_ENV_EXTRAWHITE="${BB_ENV_EXTRAWHITE_OE}
> $BB_ENV_EXTRAWHITE"
>
> If ${BB_ENV_EXTRAWHITE_OE} is found in ${BB_ENV_EXTRAWHITE} (e.g. if
> oe-init-build-env is re-run from a shell where it has already been run before),
> then this change cause oe-buildenv-internal to exit with a non-zero status,
> which will prevent oe-init-build-env from calling oe-setup-builddir or cd'ing to
> ${BUILDDIR}. Is that really the intention? It breaks my typical work flow...
>
>
> > --
> > 1.9.1
> >
> > --
> > _______________________________________________
> > Openembedded-core mailing list
> > Openembedded-core@lists.openembedded.org
> > http://lists.openembedded.org/mailman/listinfo/openembedded-core
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2015-12-21 17:00 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-12-03 23:09 [PATCH 1/2] buildtools-tarball.bb: 32bit tools need pseudo 32bit library Juro Bystricky
2015-12-03 23:09 ` [PATCH 2/2] oe-buildenv-internal: preserve existing BB_ENV_EXTRAWHITE Juro Bystricky
2015-12-14 23:47 ` Andre McCurdy
2015-12-21 17:00 ` Bystricky, Juro
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.