When using `PACKAGECONFIG = "python"` in the boost recipe, `bitbake boost`
fails at do_compile with:
./boost/python/detail/wrap_python.hpp:50:23: fatal error: pyconfig.h: No
such file or directory
compilation terminated.
This issue is due to the recent version upgrade from python 3.4 to
Ok I have found the cause of the problem. It seems that assigning anything to
TOOLCHAIN_HOST_TASK even with the += operator invalidates the
"TOOLCHAIN_HOST_TASK ?= "nativesdk-packagegroup-sdk-host
packagegroup-cross-canadian-${MACHINE}" statement that can be found in
https://github.com/openembe
I have determined that the script is most likely failing at the end of
https://github.com/openembedded/openembedded-core/blob/fido/meta/files/toolchain-shar-extract.sh
indicating that the environment-setup file is never created (or copied I
guess). I have also found that simply using something l
On Sun, Dec 6, 2015 at 9:47 AM, Martin Jansa wrote:
> See:
>
> http://lists.openembedded.org/pipermail/openembedded-core/2015-November/112919.html
>
> I think it fixes the same issue.
Close, but not quite, I think. It doesn't look like it addresses the
ordering mismatch that occurs due to the -v
See:
http://lists.openembedded.org/pipermail/openembedded-core/2015-November/112919.html
I think it fixes the same issue.
On Sun, Dec 6, 2015 at 6:09 PM, Matt Madison wrote:
> I was trying some multilib ARM builds and ran into an issue. For
> armv7ahf-neon-vfpv4, PACKAGE_EXTRA_ARCHS is coded
Have DPKG_ARCH set by directly invoking a mapping function, rather
than using an anonymous Python function modify the variable under
the hood, so we can have proper handling of overrides.
Also bring in some additional mappings to Debian architecture names
that weren't being handled.
Signed-off-by
* tmp/deploy/deb subdirectories do not get hyphens replaced
with underscores, so don't do that translation when building
the sources list.
* Fix MULTILIB_VARIANTS handling to be more general and
work for all architectures
* Also include a fix for a warning generated by apt
due to missing
I ran into sevearl issues while trying to build an ARM multilib rootfs
using Debian packaging. After several go-rounds, it looked like the
cleanest solution was to tweak how DPKG_ARCH gets constructed and
to have the DpkgPM class in oe/package_manager.py use that variable
to locate multilib varian
I was trying some multilib ARM builds and ran into an issue. For
armv7ahf-neon-vfpv4, PACKAGE_EXTRA_ARCHS is coded as "armv7ahf-vfp-neon-vfpv4",
but the ARMPKGSFX_FPU suffix was getting constructed as "-vfp-vfpv4-neon",
resulting
in 32-bit packages not getting found due to the name mismatch.
The
Make the feature order in ARMPKGSFX_FPU match that used in
PACKAGE_EXTRA_ARCHS when both neon and vfpv4 are enabled.
Signed-off-by: Matt Madison
---
meta/conf/machine/include/arm/feature-arm-neon.inc | 2 +-
meta/conf/machine/include/arm/feature-arm-vfp.inc | 2 +-
2 files changed, 2 insertions
This follows how bitbake performs path insertion, and fixes a
failure to start wic on Ubuntu 15.10 with the distribution's
version of python-ply installed.
Signed-off-by: Matt Madison
---
scripts/wic | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/scripts/wic b/scripts/wi
On Sun, Dec 6, 2015 at 6:16 AM, Robert P. J. Day
wrote:
> possibly a stupid question, but i'm looking at a publicly available
> OE layer and, in layer.conf, there is a setting for BBFILES that pulls
> in a number of subdirectories and ends with:
>
> ... snip ...
> ${LAYERDIR}/re
I am not sure why this is happening but it seems as if though the packagegroup
class is causing generated SDKs to be corrupt on my system. I could run -c
populate_sdk just fine on my system and image and the resulting SDK was just
fine too. The problem was that it did not include the needed Qt
possibly a stupid question, but i'm looking at a publicly available
OE layer and, in layer.conf, there is a setting for BBFILES that pulls
in a number of subdirectories and ends with:
... snip ...
${LAYERDIR}/recipes-*/*/*.bbappend \
${LAYERDIR}/classes/*.bbclass"
i a
> Am 03.12.2015 um 17:45 schrieb Mariano Lopez :
>
> [...]
>
> Thanks to all for your input. The conclusion of this thread is:
>
> 1. One size doesn't fit all.
> 2. Most of the people was fine with the image based update.
Where is the image stored? I read over referred
http://sbabic.github.io
In the Linux 3.10.y series, repeatedly running 'make scripts' causes the modpost
script to be rebuilt every time. This causes a potential race condition when
building multiple external modules against a 3.10.y series kernel: one recipe
may be running do_make_scripts and modifying modpost whilst ano
I ran into a race condition building multiple external modules against a 3.10.y
series kernel using the dylan branch of OpenEmbedded. This is difficult to
reproduce as it requires very specific timing: the do_make_scripts task for one
module was linking the modpost script whilst the do_compile task
you also need to backport
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=fd16f36d1986fbbb9f802b3649e543f3f41227ea
along with the others
On Thu, Dec 3, 2015 at 6:01 PM, Yuanjie Huang
wrote:
> From: Yuanjie Huang
>
> The std::random_device class in libstdc++ in the GNU Compiler Collection
> (aka
18 matches
Mail list logo
