Ok, I moved past t= hat above error as well. I edited the image recipe, and just commented out = the packages that aren't ready for lib32 build yet.

Unfort= unately, even when I build with lib32-<image name> -c populate_sdk, t= he sysroots for armv7 aren't getting populated. Also, the environment s= etup script does not work properly. (i.e., the environment variable $CC poi= nts to a file that does not exist).

Here is the name of the ou= tput in tmp/deploy/sdk:
poky-glibc-x86_64-lib32-<image name>-aarch64-toolchain-2.0.1.sh
=

As you can see, the TUNE_PKGARCH is still set to aarch64. In fact= , when I first run the bitbake command, this is what I see:

$ bitb= ake lib32-<image name> -c populate_sdk
Build Configuration:
BB_= VERSION=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =3D "1.28.0"BUILD_SYS=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =3D "x86_64= -linux"
NATIVELSBSTRING=C2=A0=C2=A0 =3D "Ubuntu-14.04"TARGET_SYS=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =3D "aarch64-pok= y-linux"
MACHINE=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 =3D "qcom-bsp"
DISTRO=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =3D "poky"
DISTRO_VERSION= =C2=A0=C2=A0=C2=A0 =3D "2.0.1"
TUNE_FEATURES=C2=A0=C2= =A0=C2=A0=C2=A0 =3D "aarch64"
TARGET_FPU=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =3D ""

It seems this = is coming from the MACHINE file, which includes this line:
require conf/= machine/include/arm/arch-armv8.inc

That file just has a single= line in it:
=C2=A0requires conf/machine/include/arm/arch-arm64.inc
<= br>THAT file immediately sets the DEFAULTTUNE to aarch64.

So, = how am I supposed to enable armv7 SDK to be built? Shouldn't the DEFAUL= TTUNE be set to armv7-neon for this to work?

Am I missing somethin= g simple? I've read through the documentation a few times, but fully ad= mit that bitbake is large and complex and I may be missing something.

On Mon, Aug 1, 2016 at 4:05 PM, Nemicolopte= rus Crypticus <ncrypticus@gmail.com> wrote:

Ok, I've made some= progress.
I'm running
$bitbake lib32-<image name> -c popu= late_sdk

and it proceeds for a while.
We do have a few packages t= hat are not ready to be built as 32-bit, and those fail as compiler errors.=

Is there a way to temporarily remove them from the list of pa= ckages to be built?

Poking around I found DEFAULT_PREFERENCE*, but= that looks like it's not quite what I'm looking for.

= Is there any easy way to quickly disable a particular package from an image= build?

* http://www.embeddedlinux.o= rg.cn/OEManual/recipes_defaultpreference.html

On Fri, Jul 29, 2016 at 1:30 PM, Nemicolopterus Crypticus = <ncrypticus@gmail.com> wrote:

Added: https://bugzilla.yoctoproj= ect.org/show_bug.cgi?id=3D10054

Please let me kno= w if I can try anything else or provide more info.

In the= meantime, I'm going to try to disable multilib, and only build the ARM= v7 version of the SDK.
On Fri, Jul 29, 2016 at 12:07 PM, Khem R= aj <raj.khem@gmail.com> wrote:
On Jul 29, 2016, at 10:48 AM, Nemicolopterus Crypticus <<= a href=3D"mailto:ncrypticus@gmail.com" target=3D"_blank">ncrypticus@gmail.c= om> wrote:

Hello all,
We are having issues with our=20 generated SDK files. We're using the jethro branch, and have enabled=20 multilib (see relevant portion of local.conf below).

I ca= n succesfully run the command to generate the SDK:
$ bitbake = <recipe name> -c populate_sdk

But the output is inc= orrect. While the aarch sysroots look good, the sysroots for arm are completely=20 missing. The environment setup script ends up pointing to non-existent=20 compilers. Please let me know if you need more information!
Thanks for report. It wil= l be good if you can open a bugzilla entry for this. So it can be tracked.<= /div>
Steps to reproduce:
$ bitbake <recipe name>= -c populate_sdk
$ cp tmp/deploy/sdk/<sdk-script>.sh /t= est/directory
$ cd /test/directory
$ bash <s= dk-script>.sh
$ ls sysroots/
aarch64-poky-linux/=C2=A0= =C2=A0 x86_64-pokysdk-linux/

Note the missing ARM direct= ories.

Also, the setup script for arm sets this as the co= mmand for compiler:
=C2=A012 export CC=3D"arm-pokymllib32-linux-gnu= eabi-gcc

But that compiler doesn't exist anywhere in = the folder where I installed everything, or environment!

= So it appears that it's not completely or correctly packaging everythin= g for ARMv7.

The documentation does mention some environment variables, but = it's not clear how those related to multilib.

For instance, none of our recipes have "SDKIMAGE_FEATURES" defined, = but=20 clearly the aarch64 sysroots are getting populated correctly (we=20 succesfully compiled and ran a simple hello world).
Ca= n anyone point me to an example, or discuss a successful use of=20 "multilib" on the Jethro branch (given desparate brainstorming be= low),=20 share some more verbose documentation, or ask follow-up questions?
<= /div>

______________________________________________= _______________
Desperate brainstorming below:
= I did find this years-old patch: https://patchwork.openembedded.org/patc= h/30941/
Notably, the do_populate_sdk method in poky/meta= /classes/populate_sdk_base.bbclass iterates over the values listed in the M= ULTILIB_VARIANTS variable:
+	variants =3D d.getVar("=
MULTILIB_VARIANTS", True) or ""
+	for item in variants.split():
+		# Load overrides from 'd' to avoid having to reset the val=
ue...
+		overrides =3D d.getVar("OVERRIDES", False) + ":virt=
class-multilib-" + item
+		localdata.setVar("OVERRIDES", overrides)
+		bb.data.update_data(localdata)
+		bb.build.exec_func("create_sdk_files", localdata)=
The latest version in Jethro does not h= ave anything equivalent to that, but I did not dig deeply into the code or = the commit history.

_________________________= _____________________________________
More data:
local.conf relevant section:
#
# Multilib configuration#
# This sets any packages preprended with lib32- to be built with
= # the armv7a tuning (32 bit) instead of 64 bit aarch.
#
require conf/= multilib.conf
MULTILIBS =3D "multilib:lib32"
DEFAULTTUNE_vi= rtclass-multilib-lib32 =3D "armv7at-neon"
= --
_______________________________________________
Openembedded-core= mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-co= re