Re: x86_64 kernel with i586 userland plus SDK?

Richard Weinberger


On Wed, Nov 28, 2018 at 9:42 AM Richard Purdie
<richard.purdie@...> wrote:
But it seems that building and SDK is currently broken/disabled:

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
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 present.
I did a search for and found these files in the SDK install directory:


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.


Join to automatically receive all group messages.