x86_64 kernel with i586 userland plus SDK?

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.

-- 
Thanks,
//richard

Re: x86_64 kernel with i586 userland plus SDK?

[ChenQi]

On 11/28/2018 05:46 AM, Richard Weinberger wrote:
> 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

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

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

Re: x86_64 kernel with i586 userland plus SDK?

[Richard Purdie]

Hi,

On Tue, 2018-11-27 at 22:46 +0100, Richard Weinberger wrote:
> 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

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.

> 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

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

> 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

Re: x86_64 kernel with i586 userland plus SDK?

[Richard Weinberger]

Richard,

On Wed, Nov 28, 2018 at 9:42 AM Richard Purdie
<richard.purdie@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

Re: x86_64 kernel with i586 userland plus SDK?

[Richard Weinberger]

On Wed, Nov 28, 2018 at 9:26 PM Richard Weinberger
<richard.weinberger@gmail.com> wrote:
>
> Richard,
>
> On Wed, Nov 28, 2018 at 9:42 AM Richard Purdie
> <richard.purdie@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?

*kind ping*

-- 
Thanks,
//richard

Re: x86_64 kernel with i586 userland plus SDK?

[richard.purdie]

On Mon, 2018-12-03 at 09:52 +0100, Richard Weinberger wrote:
> On Wed, Nov 28, 2018 at 9:26 PM Richard Weinberger
> <richard.weinberger@gmail.com> wrote:
> > Richard,
> > 
> > On Wed, Nov 28, 2018 at 9:42 AM Richard Purdie
> > <richard.purdie@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?
> 
> *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

Re: x86_64 kernel with i586 userland plus SDK?

[Richard Weinberger]

On Wed, Nov 28, 2018 at 9:42 AM Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
> 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 went this approach for now.
That way I get i586 userland and an SDK with both 32bit and 64bit toolchains.
The SDK offers me multiple environment files to include.

What I don't understand right now is, how can i tell the kernel recipe
that it has
to use the 64bit toolchain to build the kernel?

Any hints?

-- 
Thanks,
//richard

Re: x86_64 kernel with i586 userland plus SDK?

[richard.purdie]

On Mon, 2018-12-17 at 11:26 +0100, Richard Weinberger wrote:
> On Wed, Nov 28, 2018 at 9:42 AM Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
> > 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 went this approach for now.
> That way I get i586 userland and an SDK with both 32bit and 64bit
> toolchains.
> The SDK offers me multiple environment files to include.
> 
> What I don't understand right now is, how can i tell the kernel
> recipe
> that it has
> to use the 64bit toolchain to build the kernel?
> 
> Any hints?

I think (but am going from memory) that the x86 toolchains can generate
64 and 32 bit code with the right compiler option. The kernel just
passes in the right options if configured to build as 64 bit even if it
has the 32 bit toolchain?

Cheers,

Richard

Re: x86_64 kernel with i586 userland plus SDK?

[Richard Weinberger]

Richard,

Am Montag, 17. Dezember 2018, 11:34:08 CET schrieb richard.purdie@linuxfoundation.org:
> On Mon, 2018-12-17 at 11:26 +0100, Richard Weinberger wrote:
> > On Wed, Nov 28, 2018 at 9:42 AM Richard Purdie
> > <richard.purdie@linuxfoundation.org> wrote:
> > > 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 went this approach for now.
> > That way I get i586 userland and an SDK with both 32bit and 64bit
> > toolchains.
> > The SDK offers me multiple environment files to include.
> > 
> > What I don't understand right now is, how can i tell the kernel
> > recipe
> > that it has
> > to use the 64bit toolchain to build the kernel?
> > 
> > Any hints?
> 
> I think (but am going from memory) that the x86 toolchains can generate
> 64 and 32 bit code with the right compiler option. The kernel just
> passes in the right options if configured to build as 64 bit even if it
> has the 32 bit toolchain?

This was my hope, and this is also what I get when doing such builds manually.
Having a x86_64 gcc and building userspace with "-m32" appended.

Yocto seems to try a different approach.
When I use qemux86-64.conf with DEFAULTTUNE being "i586" it generates a 32bit
toolchain by default.

Build Configuration:
BB_VERSION           = "1.38.0"
BUILD_SYS            = "x86_64-linux"
NATIVELSBSTRING      = "universal"
TARGET_SYS           = "i686-poky-linux"
MACHINE              = "myqemux86-64"
DISTRO               = "poky"
DISTRO_VERSION       = "2.5.1"
TUNE_FEATURES        = "m32 i586"

What I need is a x86_64-poky-linux toolchain with -m32 set for everything except
kernel (and modules).

Thanks,
//richard

-- 
sigma star gmbh - Eduard-Bodem-Gasse 6 - 6020 Innsbruck - Austria
ATU66964118 - FN 374287y

Re: x86_64 kernel with i586 userland plus SDK?

[Richard Weinberger]

[Resending with correct mail]

Richard,

On Mon, Dec 17, 2018 at 11:34 AM <richard.purdie@linuxfoundation.org> wrote:
>
> On Mon, 2018-12-17 at 11:26 +0100, Richard Weinberger wrote:
> > On Wed, Nov 28, 2018 at 9:42 AM Richard Purdie
> > <richard.purdie@linuxfoundation.org> wrote:
> > > 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 went this approach for now.
> > That way I get i586 userland and an SDK with both 32bit and 64bit
> > toolchains.
> > The SDK offers me multiple environment files to include.
> >
> > What I don't understand right now is, how can i tell the kernel
> > recipe
> > that it has
> > to use the 64bit toolchain to build the kernel?
> >
> > Any hints?
>
> I think (but am going from memory) that the x86 toolchains can generate
> 64 and 32 bit code with the right compiler option. The kernel just
> passes in the right options if configured to build as 64 bit even if it
> has the 32 bit toolchain?

This was my hope, and this is also what I get when doing such builds manually.
Having a x86_64 gcc and building userspace with "-m32" appended.

Yocto seems to try a different approach.
When I use qemux86-64.conf with DEFAULTTUNE being "i586" it generates a 32bit
toolchain by default.

Build Configuration:
BB_VERSION           = "1.38.0"
BUILD_SYS            = "x86_64-linux"
NATIVELSBSTRING      = "universal"
TARGET_SYS           = "i686-poky-linux"
MACHINE              = "myqemux86-64"
DISTRO               = "poky"
DISTRO_VERSION       = "2.5.1"
TUNE_FEATURES        = "m32 i586"

What I need is a x86_64-poky-linux toolchain with -m32 set for everything except
kernel (and modules).

-- 
Thanks,
//richard

Re: x86_64 kernel with i586 userland plus SDK?

[Bruce Ashfield]

On 12/17/18 7:25 AM, Richard Weinberger wrote:
> [Resending with correct mail]
> 
> Richard,
> 
> On Mon, Dec 17, 2018 at 11:34 AM <richard.purdie@linuxfoundation.org> wrote:
>>
>> On Mon, 2018-12-17 at 11:26 +0100, Richard Weinberger wrote:
>>> On Wed, Nov 28, 2018 at 9:42 AM Richard Purdie
>>> <richard.purdie@linuxfoundation.org> wrote:
>>>> 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 went this approach for now.
>>> That way I get i586 userland and an SDK with both 32bit and 64bit
>>> toolchains.
>>> The SDK offers me multiple environment files to include.
>>>
>>> What I don't understand right now is, how can i tell the kernel
>>> recipe
>>> that it has
>>> to use the 64bit toolchain to build the kernel?
>>>
>>> Any hints?
>>
>> I think (but am going from memory) that the x86 toolchains can generate
>> 64 and 32 bit code with the right compiler option. The kernel just
>> passes in the right options if configured to build as 64 bit even if it
>> has the 32 bit toolchain?
> 
> This was my hope, and this is also what I get when doing such builds manually.
> Having a x86_64 gcc and building userspace with "-m32" appended.
> 
> Yocto seems to try a different approach.
> When I use qemux86-64.conf with DEFAULTTUNE being "i586" it generates a 32bit
> toolchain by default.
> 
> Build Configuration:
> BB_VERSION           = "1.38.0"
> BUILD_SYS            = "x86_64-linux"
> NATIVELSBSTRING      = "universal"
> TARGET_SYS           = "i686-poky-linux"
> MACHINE              = "myqemux86-64"
> DISTRO               = "poky"
> DISTRO_VERSION       = "2.5.1"
> TUNE_FEATURES        = "m32 i586"
> 
> What I need is a x86_64-poky-linux toolchain with -m32 set for everything except
> kernel (and modules).

For the most part the kernel builds do not take any flags from the
outside, i.e. they are all generated based on the kernel build
structure, not what is calling the build. (unless you bury flags
into the definition of $(CC), etc, but I wouldn't recommend that.

So if you have a 64 bit capable toolchain, have a 64 bit configured
kernel (i.e. CONFIG_64BIT=y), are passing -m32 to usespace .. the
kernel really should build 64bit.

Have you tried that and are seeing the kernel still be built with the
32bit toolchain ?

Bruce


> 

Re: x86_64 kernel with i586 userland plus SDK?

[Richard Weinberger]

Bruce,

On Mon, Dec 17, 2018 at 2:47 PM Bruce Ashfield
<bruce.ashfield@windriver.com> wrote:
> > Yocto seems to try a different approach.
> > When I use qemux86-64.conf with DEFAULTTUNE being "i586" it generates a 32bit
> > toolchain by default.
> >
> > Build Configuration:
> > BB_VERSION           = "1.38.0"
> > BUILD_SYS            = "x86_64-linux"
> > NATIVELSBSTRING      = "universal"
> > TARGET_SYS           = "i686-poky-linux"
> > MACHINE              = "myqemux86-64"
> > DISTRO               = "poky"
> > DISTRO_VERSION       = "2.5.1"
> > TUNE_FEATURES        = "m32 i586"
> >
> > What I need is a x86_64-poky-linux toolchain with -m32 set for everything except
> > kernel (and modules).
>
> For the most part the kernel builds do not take any flags from the
> outside, i.e. they are all generated based on the kernel build
> structure, not what is calling the build. (unless you bury flags
> into the definition of $(CC), etc, but I wouldn't recommend that.
>
> So if you have a 64 bit capable toolchain, have a 64 bit configured
> kernel (i.e. CONFIG_64BIT=y), are passing -m32 to usespace .. the
> kernel really should build 64bit.

This was my plan, but yocto always create a 32bit toolchain when
it set DEFAULTTUNE to i586 for a 64bit machine.

> Have you tried that and are seeing the kernel still be built with the
> 32bit toolchain ?

Yes, it builds with i686-poky-linux. :-(

-- 
Thanks,
//richard

Re: x86_64 kernel with i586 userland plus SDK?

[Bruce Ashfield]

On 12/17/18 8:50 AM, Richard Weinberger wrote:
> Bruce,
> 
> On Mon, Dec 17, 2018 at 2:47 PM Bruce Ashfield
> <bruce.ashfield@windriver.com> wrote:
>>> Yocto seems to try a different approach.
>>> When I use qemux86-64.conf with DEFAULTTUNE being "i586" it generates a 32bit
>>> toolchain by default.
>>>
>>> Build Configuration:
>>> BB_VERSION           = "1.38.0"
>>> BUILD_SYS            = "x86_64-linux"
>>> NATIVELSBSTRING      = "universal"
>>> TARGET_SYS           = "i686-poky-linux"
>>> MACHINE              = "myqemux86-64"
>>> DISTRO               = "poky"
>>> DISTRO_VERSION       = "2.5.1"
>>> TUNE_FEATURES        = "m32 i586"
>>>
>>> What I need is a x86_64-poky-linux toolchain with -m32 set for everything except
>>> kernel (and modules).
>>
>> For the most part the kernel builds do not take any flags from the
>> outside, i.e. they are all generated based on the kernel build
>> structure, not what is calling the build. (unless you bury flags
>> into the definition of $(CC), etc, but I wouldn't recommend that.
>>
>> So if you have a 64 bit capable toolchain, have a 64 bit configured
>> kernel (i.e. CONFIG_64BIT=y), are passing -m32 to usespace .. the
>> kernel really should build 64bit.
> 
> This was my plan, but yocto always create a 32bit toolchain when
> it set DEFAULTTUNE to i586 for a 64bit machine.
> 
>> Have you tried that and are seeing the kernel still be built with the
>> 32bit toolchain ?
> 
> Yes, it builds with i686-poky-linux. :-(

It's Monday, and I've only had half a coffee .. so bear with me. When
I see i686, I'd expect that without -m32 it is generating 64bit by
default .. so there's definitely a -m32 sneaking into the definition of
CC for the kernel build ?

Do you have a dump of the kernel build line that I could see ?

Bruce

> 

Re: x86_64 kernel with i586 userland plus SDK?

[Richard Weinberger]

Bruce,

On Mon, Dec 17, 2018 at 2:54 PM Bruce Ashfield
<bruce.ashfield@windriver.com> wrote:
> > Yes, it builds with i686-poky-linux. :-(
>
> It's Monday, and I've only had half a coffee .. so bear with me. When
> I see i686, I'd expect that without -m32 it is generating 64bit by
> default .. so there's definitely a -m32 sneaking into the definition of
> CC for the kernel build ?

If I understand the problem correctly, the root of the problem is that yocto
"degrades" to i686.

When I set DEFAULTTUNE to i586 for a 64bit machine I'd expect
TARGET_SYS still being x86_64-poky-linux.
But it is i686-poky-linux.

> Do you have a dump of the kernel build line that I could see ?

Sure, let me trigger a rebuild, currently my yocto is in limbo-state. :)
So might take some time.

-- 
Thanks,
//richard

Re: x86_64 kernel with i586 userland plus SDK?

[Richard Weinberger]

Bruce,

On Mon, Dec 17, 2018 at 3:00 PM Richard Weinberger
<richard.weinberger@gmail.com> wrote:
> When I set DEFAULTTUNE to i586 for a 64bit machine I'd expect
> TARGET_SYS still being x86_64-poky-linux.
> But it is i686-poky-linux.
>
> > Do you have a dump of the kernel build line that I could see ?
>
> Sure, let me trigger a rebuild, currently my yocto is in limbo-state. :)
> So might take some time.

I think I found the source if my confusion, the i686-poky-linux compiler
*is* a biarch gcc but defaults to -m32.
When I pass -m64 to it, it actually generates proper x86_64 code.

Although, the kernel recipe always thinks that I want to build for i586 and
selects a 32bit config. But that should be easy solvable.

-- 
Thanks,
//richard