[yocto] x86_64 kernel with i586 userland plus SDK?

[Richard Weinberger]

Hi!

I have a hard time understanding how to build a distro with x86_64
kernel, i586 userland
and an SDK for that.
In the beginning I assumed and have been told on IRC that multilib is
the way to go.

But it seems that building and SDK is currently broken/disabled:
http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=e153efde9754a650e555f46cba09680baabd7d7e

Another issue,if I try to add lib32 packages to my x86_64 image
building the rootfs fails due
to such odd apt errors:
The following packages have unmet dependencies:
lib32-packagegroup-core-ssh-dropbear : Depends: lib32-dropbear but it
is not installable
lib32-packagegroup-core-x11-base : Depends: lib32-dbus-1 but it is
not installable
Depends: lib32-matchbox-terminal
but it is not installable
Depends: lib32-matchbox-wm but it
is not installable
Depends: lib32-mini-x-session but
it is not installable
Depends:
lib32-packagegroup-core-x11-utils but it is not going to be installed
Depends:
lib32-packagegroup-core-x11-xserver but it is not installable

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.

[ChenQi]

Post by Richard Weinberger
Hi!
I have a hard time understanding how to build a distro with x86_64
kernel, i586 userland
and an SDK for that.
In the beginning I assumed and have been told on IRC that multilib is
the way to go.
http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=e153efde9754a650e555f46cba09680baabd7d7e

The above issue has been filed a bug in bugzilla.
https://bugzilla.yoctoproject.org/show_bug.cgi?id=13047

I've also added my comments there.

Best Regards,
Chen Qi

Post by Richard Weinberger
Another issue,if I try to add lib32 packages to my x86_64 image
building the rootfs fails due
lib32-packagegroup-core-ssh-dropbear : Depends: lib32-dropbear but it
is not installable
lib32-packagegroup-core-x11-base : Depends: lib32-dbus-1 but it is
not installable
Depends: lib32-matchbox-terminal
but it is not installable
Depends: lib32-matchbox-wm but it
is not installable
Depends: lib32-mini-x-session but
it is not installable
lib32-packagegroup-core-x11-utils but it is not going to be installed
lib32-packagegroup-core-x11-xserver but it is not installable
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.

--

[Richard Purdie]

Hi,

Post by Richard Weinberger
I have a hard time understanding how to build a distro with x86_64
kernel, i586 userland
and an SDK for that.
In the beginning I assumed and have been told on IRC that multilib is
the way to go.

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.

Post by Richard Weinberger
Another issue,if I try to add lib32 packages to my x86_64 image
building the rootfs fails due
lib32-packagegroup-core-ssh-dropbear : Depends: lib32-dropbear but it
is not installable
lib32-packagegroup-core-x11-base : Depends: lib32-dbus-1 but it is
not installable
Depends: lib32-matchbox-terminal
but it is not installable
Depends: lib32-matchbox-wm but it
is not installable
Depends: lib32-mini-x-session but
it is not installable
lib32-packagegroup-core-x11-utils but it is not going to be installed
lib32-packagegroup-core-x11-xserver but it is not installable

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

Post by Richard Weinberger
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...

Cheers,

Richard



--

[Richard Weinberger]

Richard,

On Wed, Nov 28, 2018 at 9:42 AM Richard Purdie

Post by Richard Weinberger
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?

Post by Richard Weinberger
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!

Post by Richard Weinberger

Post by Richard Weinberger
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.

[Richard Weinberger]

On Wed, Nov 28, 2018 at 9:26 PM Richard Weinberger

Post by Richard Weinberger
Richard,
On Wed, Nov 28, 2018 at 9:42 AM Richard Purdie

Post by Richard Weinberger
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.
./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?

*kind ping*

[r***@linuxfoundation.org]

Post by Richard Weinberger
On Wed, Nov 28, 2018 at 9:26 PM Richard Weinberger

Post by Richard Weinberger
Richard,
On Wed, Nov 28, 2018 at 9:42 AM Richard Purdie

Post by Richard Weinberger

Post by Richard Weinberger
But it seems that building and SDK is currently

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.
./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?

*kind ping*

This is the bug that Qi opened. The code doesn't do what you want right
now and I'm not sure how easy/hard it would be to make it do the above
:(

Sorry, I hadn't realised we had this problem until you dived into it
although it is kind of obvious in hindsight...

Cheers,

Richard


--