[yocto] x86_64 kernel with i586 userland plus SDK?

[Richard Weinberger]

Richard,

On Wed, Nov 28, 2018 at 9:42 AM Richard Purdie
<richard.purdie at linuxfoundation.org> wrote:
> > But it seems that building and SDK is currently broken/disabled:
> >
> http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=e153efde9754a650e555f46cba09680baabd7d7e
>
> I see a bug was opened for this but its not valid and this shouldn't be
> an issue. Keep in mind that an SDK contains all multilibs so "bitbake
> X-image -c populate_sdk" would be equivalent to "bitbake libXX-X-image
> -c populate_sdk" and be the same thing. One didn't work so we remove
> that.

My idea was having a 32bit only SDK. In my case I really don't need
64bit userspace.
On the other hand, having both 32bit and 64bit libs in the SDK is not
a big deal right now.

So I did "bitbake my-image -c populate_sdk" but the resulting SDK
seems to contain no
32bits libraries.
TOOLCHAIN_TARGET_TASK contains "openssl", so I expected libssl.so present.
I did a search for libssl.so and found these files in the SDK install directory:

./tmp/sysroots/mymachine/usr/lib64/libssl.so.1.0.2
./tmp/sysroots/mymachine/usr/lib/libssl.so.1.0.2

Both files are 64bit shared libraries :-(

What do I miss?

> Unfortunately the debian backend is the least supported for multilibs
> and I suspect you'd have better luck with ipk or rpm.

Indeed, switching to rpm did wonders. Thanks a lot for the hint!

> > Are there other possibilities?
> > Userspace can be pure i586, so full multilib support is not needed.
> > Having a x86_64 toolchain should be goof enough, it could build
> > userspace with -m32 and the kernel as-is.
>
> The system can definitely do it, its just not something we tend to do
> very often so its not entirely clear the best way to do it.
>
> What may work is selecting the i586 tune from an x64-64 target machine?
>
> Copying qemux86-64.conf to qemux86-64-2.conf and changing it to have
> DEFAULTTUNE ?= "i586" did appear to start to build at least in a quick
> test here...

I'll give that a try after sorting out my multilib confusion.
Using a sane/supported method seems more future-prove to me.

-- 
Thanks,
//richard