Intel machine with 64 Bit kernel and 32 Bit user space

Intel machine with 64 Bit kernel and 32 Bit user space

[Ayoub Zaki]

[-- Attachment #1: Type: text/plain, Size: 190 bytes --]

Hi list,

Is it possible to define a MACHINE configuration with a 64 Bit kernel and
32 Bit user space ?

The user space should not be using a  x32 ABI.


Thank you!

best regards

[-- Attachment #2: Type: text/html, Size: 843 bytes --]

Re: Intel machine with 64 Bit kernel and 32 Bit user space

[Alexander Kanavin]

2018-07-26 14:56 GMT+02:00 Ayoub Zaki <ayoub.zaki@googlemail.com>:
> Is it possible to define a MACHINE configuration with a 64 Bit kernel and 32
> Bit user space ?
>
> The user space should not be using a  x32 ABI.

I think (but I am not sure), that you can do it with multilib. Define
a configuration like this:
https://github.com/openembedded/openembedded-core/blob/master/meta-skeleton/conf/multilib-example.conf

Then build lib32-core-image-minimal. That image should include only 32
bit user space, but the kernel will be 64 bit.

Alex

Re: Intel machine with 64 Bit kernel and 32 Bit user space

[Mark Hatle]

On 7/26/18 10:19 AM, Alexander Kanavin wrote:
> 2018-07-26 14:56 GMT+02:00 Ayoub Zaki <ayoub.zaki@googlemail.com>:
>> Is it possible to define a MACHINE configuration with a 64 Bit kernel and 32
>> Bit user space ?
>>
>> The user space should not be using a  x32 ABI.
> 
> I think (but I am not sure), that you can do it with multilib. Define
> a configuration like this:
> https://github.com/openembedded/openembedded-core/blob/master/meta-skeleton/conf/multilib-example.conf
> 
> Then build lib32-core-image-minimal. That image should include only 32
> bit user space, but the kernel will be 64 bit.

Yes this is the typical approach.  Enable multilibs, and then build the image
you you want with the approach multilib prefix.

This works in any multilib configurations, 64-bit, 32-bit, x32, etc..

--Mark

> Alex
> 

Re: Intel machine with 64 Bit kernel and 32 Bit user space

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 2989 bytes --]

It's not as simple as that in some cases, there are some components which
are pulled in 64bit version even when building lib32-foo-image.

Some are easy to override from the config e.g.:
ROOTFS_PKGMANAGE = "${LIB32_PREFIX}opkg"
SPLASH = "${LIB32_PREFIX}psplash"

but to prevent building e.g. syslinux in 64bit version is a bit more tricky.

syslinux.bbclass was fixed long time ago:
commit c8dc421ea18bb7a810501ab6d07efa9c8f6d6eb9
Author: Ming Liu <ming.liu@windriver.com>
Date:   Thu Jun 19 16:42:58 2014 +0800

    syslinux.bbclass: Ensure MLPREFIX is applied to depends flag

    Add MLPREFIX to depends flag to ensure the correct syslinux is
    dependended upon.

-do_bootimg[depends] += "syslinux:do_populate_sysroot \
+do_bootimg[depends] += "${MLPREFIX}syslinux:do_populate_sysroot \

but wic still depends on syslinux without MLPREFIX:

meta/conf/machine/qemux86-64.conf:do_image_wic[depends] +=
"syslinux:do_populate_sysroot syslinux-native:do_populate_sysroot
mtools-native:do_populate_sysroot dosfstools-nat...
meta/conf/machine/qemux86.conf:do_image_wic[depends] +=
"syslinux:do_populate_sysroot syslinux-native:do_populate_sysroot
mtools-native:do_populate_sysroot dosfstools-native...

similarly opkg-utils and some other components are pulled in the
not-prefixed version even when building image with a prefix. I've
eventually got it working with morty (that it was really building only
couple 64bit recipes, mostly kernel and recipes providing external modules
and e.g. depmodwrapper-cross), but it's kind of shaky and error prone, I'll
send fixes for some of these issues, but as we're using morty it's more
complicated to find out what is still needed and what was resolved in newer
OE already.

And there are the issues with allarch recipes mentioned in the other
multilib thread.

Regards,


On Thu, Jul 26, 2018 at 5:59 PM Mark Hatle <mark.hatle@windriver.com> wrote:

> On 7/26/18 10:19 AM, Alexander Kanavin wrote:
> > 2018-07-26 14:56 GMT+02:00 Ayoub Zaki <ayoub.zaki@googlemail.com>:
> >> Is it possible to define a MACHINE configuration with a 64 Bit kernel
> and 32
> >> Bit user space ?
> >>
> >> The user space should not be using a  x32 ABI.
> >
> > I think (but I am not sure), that you can do it with multilib. Define
> > a configuration like this:
> >
> https://github.com/openembedded/openembedded-core/blob/master/meta-skeleton/conf/multilib-example.conf
> >
> > Then build lib32-core-image-minimal. That image should include only 32
> > bit user space, but the kernel will be 64 bit.
>
> Yes this is the typical approach.  Enable multilibs, and then build the
> image
> you you want with the approach multilib prefix.
>
> This works in any multilib configurations, 64-bit, 32-bit, x32, etc..
>
> --Mark
>
> > Alex
> >
>
> --
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>

[-- Attachment #2: Type: text/html, Size: 4199 bytes --]

Re: Intel machine with 64 Bit kernel and 32 Bit user space

[Ayoub Zaki]

[-- Attachment #1: Type: text/plain, Size: 6932 bytes --]

Hello all,

thanks for the suggestions: I tried the multilib concept of yocto but as
Martin already wrote is not that simple, my build is breaking during wic
image generation as follow:

zaki@xps:/opt/build/poky/build$ MACHINE=nx bitbake  lib32-my-image
Loading cache: 100%
|################################################################################################################################################################################|
Time: 0:00:00
Loaded 4968 entries from dependency cache.
NOTE: Resolving any missing task queue dependencies

Build Configuration:
BB_VERSION           = "1.38.0"
BUILD_SYS            = "x86_64-linux"
NATIVELSBSTRING      = "universal"
TARGET_SYS           = "x86_64-poky-linux"
MACHINE              = "nx"
DISTRO               = "poky"
DISTRO_VERSION       = "V00.00.00.00+20180727100935"
TUNE_FEATURES        = "m64 core2"
TARGET_FPU           = ""
meta
meta-poky
meta-yocto-bsp       = "sumo:90f7edb32ac2500d93bb7ca5045a9d048f551223"
meta-intel           = "sumo:2430f73ee06f3315ebebe69899f1977f9a09e29f"
meta-oe
meta-networking
meta-webserver
meta-python          = "sumo:b0950aeff5b630256bb5e25ca15f4d59c115e7c1"

Initialising tasks: 100%
|###########################################################################################################################################################################|
Time: 0:00:02
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
WARNING: lib32-my-image-1.0-r0 do_rootfs: lib32-systemd.postinst returned
1, marking as unpacked only, configuration required on target.
WARNING: lib32-my-image-1.0-r0 do_rootfs: Intentionally failing postinstall
scriptlets of ['lib32-systemd'] to defer them to first boot is deprecated.
Please place them into pkg_postinst_ontarget_${PN} ().
If deferring to first boot wasn't the intent, then scriptlet failure may
mean an issue in the recipe, or a regression elsewhere.
Details of the failure are in
/opt/build/poky/build/tmp/work/nx-pokymllib32-linux/lib32-my-image/1.0-r0/temp/log.do_rootfs.
WARNING: lib32-my-image-1.0-r0 do_rootfs: [log_check] lib32-my-image: found
1 warning message in the logfile:
[log_check] WARNING: Intentionally failing postinstall scriptlets of
['lib32-systemd'] to defer them to first boot is deprecated. Please place
them into pkg_postinst_ontarget_${PN} ().
ERROR: lib32-my-image-1.0-r0 do_image_wic: The file
/usr/share/gcc-7.3.0/python/libstdcxx/__init__.py is installed by both
lib32-gcc-runtime and gcc-runtime, aborting
ERROR: lib32-my-image-1.0-r0 do_image_wic: Function failed:
extend_recipe_sysroot
ERROR: Logfile of failure stored in:
/opt/build/poky/build/tmp/work/nx-pokymllib32-linux/lib32-my-image/1.0-r0/temp/log.do_image_wic.16922
ERROR: Task
(virtual:multilib:lib32:/opt/build/poky/meta-poky/recipes-core/images/my-image.bb:do_image_wic)
failed with exit code '1'
NOTE: Tasks Summary: Attempted 3460 tasks of which 3445 didn't need to be
rerun and 1 failed.

Summary: 1 task failed:

virtual:multilib:lib32:/opt/build/poky/meta-poky/recipes-core/images/my-image.bb:
do_image_wic
Summary: There were 3 WARNING messages shown.
Summary: There were 2 ERROR messages shown, returning a non-zero exit code.


The ERROR: lib32-my-image-1.0-r0 do_image_wic: The file
/usr/share/gcc-7.3.0/python/libstdcxx/__init__.py is installed by both
lib32-gcc-runtime and gcc-runtime, aborting is not self-explanatory!

gcc-runtime is anyway not part of the image ?!

any suggestions ?


thank you


Best regards

On Thu, Jul 26, 2018 at 8:12 PM, Martin Jansa <martin.jansa@gmail.com>
wrote:

> It's not as simple as that in some cases, there are some components which
> are pulled in 64bit version even when building lib32-foo-image.
>
> Some are easy to override from the config e.g.:
> ROOTFS_PKGMANAGE = "${LIB32_PREFIX}opkg"
> SPLASH = "${LIB32_PREFIX}psplash"
>
> but to prevent building e.g. syslinux in 64bit version is a bit more
> tricky.
>
> syslinux.bbclass was fixed long time ago:
> commit c8dc421ea18bb7a810501ab6d07efa9c8f6d6eb9
> Author: Ming Liu <ming.liu@windriver.com>
> Date:   Thu Jun 19 16:42:58 2014 +0800
>
>     syslinux.bbclass: Ensure MLPREFIX is applied to depends flag
>
>     Add MLPREFIX to depends flag to ensure the correct syslinux is
>     dependended upon.
>
> -do_bootimg[depends] += "syslinux:do_populate_sysroot \
> +do_bootimg[depends] += "${MLPREFIX}syslinux:do_populate_sysroot \
>
> but wic still depends on syslinux without MLPREFIX:
>
> meta/conf/machine/qemux86-64.conf:do_image_wic[depends] +=
> "syslinux:do_populate_sysroot syslinux-native:do_populate_sysroot
> mtools-native:do_populate_sysroot dosfstools-nat...
> meta/conf/machine/qemux86.conf:do_image_wic[depends] +=
> "syslinux:do_populate_sysroot syslinux-native:do_populate_sysroot
> mtools-native:do_populate_sysroot dosfstools-native...
>
> similarly opkg-utils and some other components are pulled in the
> not-prefixed version even when building image with a prefix. I've
> eventually got it working with morty (that it was really building only
> couple 64bit recipes, mostly kernel and recipes providing external modules
> and e.g. depmodwrapper-cross), but it's kind of shaky and error prone, I'll
> send fixes for some of these issues, but as we're using morty it's more
> complicated to find out what is still needed and what was resolved in newer
> OE already.
>
> And there are the issues with allarch recipes mentioned in the other
> multilib thread.
>
> Regards,
>
>
> On Thu, Jul 26, 2018 at 5:59 PM Mark Hatle <mark.hatle@windriver.com>
> wrote:
>
>> On 7/26/18 10:19 AM, Alexander Kanavin wrote:
>> > 2018-07-26 14:56 GMT+02:00 Ayoub Zaki <ayoub.zaki@googlemail.com>:
>> >> Is it possible to define a MACHINE configuration with a 64 Bit kernel
>> and 32
>> >> Bit user space ?
>> >>
>> >> The user space should not be using a  x32 ABI.
>> >
>> > I think (but I am not sure), that you can do it with multilib. Define
>> > a configuration like this:
>> > https://github.com/openembedded/openembedded-core/blob/master/meta-
>> skeleton/conf/multilib-example.conf
>> >
>> > Then build lib32-core-image-minimal. That image should include only 32
>> > bit user space, but the kernel will be 64 bit.
>>
>> Yes this is the typical approach.  Enable multilibs, and then build the
>> image
>> you you want with the approach multilib prefix.
>>
>> This works in any multilib configurations, 64-bit, 32-bit, x32, etc..
>>
>> --Mark
>>
>> > Alex
>> >
>>
>> --
>> _______________________________________________
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>>
>
> --
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
>

[-- Attachment #2: Type: text/html, Size: 11227 bytes --]

Re: Intel machine with 64 Bit kernel and 32 Bit user space

[Burton, Ross]

On 27 July 2018 at 11:23, Ayoub Zaki <ayoub.zaki@googlemail.com> wrote:
> The ERROR: lib32-my-image-1.0-r0 do_image_wic: The file
> /usr/share/gcc-7.3.0/python/libstdcxx/__init__.py is installed by both
> lib32-gcc-runtime and gcc-runtime, aborting is not self-explanatory!
>
> gcc-runtime is anyway not part of the image ?!

It will be as you'll need it to run many binaries built by gcc.

Those files should be in gcc-runtime-dbg though, so I suggest you look
at your local customisations and see why they're in that package.

See gcc-runtime.inc:

# include python debugging scripts
FILES_${PN}-dbg += "\
    ${libdir}/libstdc++.so.*-gdb.py \
    ${datadir}/gcc-${BINV}/python/libstdcxx \
"

Ross

Re: Intel machine with 64 Bit kernel and 32 Bit user space

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 7617 bytes --]

Check with bitbake -g what's pulling gcc-runtime into the image, if your
whole userspace should be 32bit, then lib32-gcc-runtime will be enough.

My multilib builds contain only following 64bit builds:
defaultpkgname  depmodwrapper-cross  linux-yocto  lttng-modules
make-mod-scripts  qemuwrapper-cross  vboxguestdrivers
the rest is 32bit

On Fri, Jul 27, 2018 at 12:23 PM Ayoub Zaki <ayoub.zaki@googlemail.com>
wrote:

> Hello all,
>
> thanks for the suggestions: I tried the multilib concept of yocto but as
> Martin already wrote is not that simple, my build is breaking during wic
> image generation as follow:
>
> zaki@xps:/opt/build/poky/build$ MACHINE=nx bitbake  lib32-my-image
> Loading cache: 100%
> |################################################################################################################################################################################|
> Time: 0:00:00
> Loaded 4968 entries from dependency cache.
> NOTE: Resolving any missing task queue dependencies
>
> Build Configuration:
> BB_VERSION           = "1.38.0"
> BUILD_SYS            = "x86_64-linux"
> NATIVELSBSTRING      = "universal"
> TARGET_SYS           = "x86_64-poky-linux"
> MACHINE              = "nx"
> DISTRO               = "poky"
> DISTRO_VERSION       = "V00.00.00.00+20180727100935"
> TUNE_FEATURES        = "m64 core2"
> TARGET_FPU           = ""
> meta
> meta-poky
> meta-yocto-bsp       = "sumo:90f7edb32ac2500d93bb7ca5045a9d048f551223"
> meta-intel           = "sumo:2430f73ee06f3315ebebe69899f1977f9a09e29f"
> meta-oe
> meta-networking
> meta-webserver
> meta-python          = "sumo:b0950aeff5b630256bb5e25ca15f4d59c115e7c1"
>
> Initialising tasks: 100%
> |###########################################################################################################################################################################|
> Time: 0:00:02
> NOTE: Executing SetScene Tasks
> NOTE: Executing RunQueue Tasks
> WARNING: lib32-my-image-1.0-r0 do_rootfs: lib32-systemd.postinst returned
> 1, marking as unpacked only, configuration required on target.
> WARNING: lib32-my-image-1.0-r0 do_rootfs: Intentionally failing
> postinstall scriptlets of ['lib32-systemd'] to defer them to first boot is
> deprecated. Please place them into pkg_postinst_ontarget_${PN} ().
> If deferring to first boot wasn't the intent, then scriptlet failure may
> mean an issue in the recipe, or a regression elsewhere.
> Details of the failure are in
> /opt/build/poky/build/tmp/work/nx-pokymllib32-linux/lib32-my-image/1.0-r0/temp/log.do_rootfs.
> WARNING: lib32-my-image-1.0-r0 do_rootfs: [log_check] lib32-my-image:
> found 1 warning message in the logfile:
> [log_check] WARNING: Intentionally failing postinstall scriptlets of
> ['lib32-systemd'] to defer them to first boot is deprecated. Please place
> them into pkg_postinst_ontarget_${PN} ().
> ERROR: lib32-my-image-1.0-r0 do_image_wic: The file
> /usr/share/gcc-7.3.0/python/libstdcxx/__init__.py is installed by both
> lib32-gcc-runtime and gcc-runtime, aborting
> ERROR: lib32-my-image-1.0-r0 do_image_wic: Function failed:
> extend_recipe_sysroot
> ERROR: Logfile of failure stored in:
> /opt/build/poky/build/tmp/work/nx-pokymllib32-linux/lib32-my-image/1.0-r0/temp/log.do_image_wic.16922
> ERROR: Task
> (virtual:multilib:lib32:/opt/build/poky/meta-poky/recipes-core/images/my-image.bb:do_image_wic)
> failed with exit code '1'
> NOTE: Tasks Summary: Attempted 3460 tasks of which 3445 didn't need to be
> rerun and 1 failed.
>
> Summary: 1 task failed:
>
> virtual:multilib:lib32:/opt/build/poky/meta-poky/recipes-core/images/my-image.bb:
> do_image_wic
> Summary: There were 3 WARNING messages shown.
> Summary: There were 2 ERROR messages shown, returning a non-zero exit code.
>
>
> The ERROR: lib32-my-image-1.0-r0 do_image_wic: The file
> /usr/share/gcc-7.3.0/python/libstdcxx/__init__.py is installed by both
> lib32-gcc-runtime and gcc-runtime, aborting is not self-explanatory!
>
> gcc-runtime is anyway not part of the image ?!
>
> any suggestions ?
>
>
> thank you
>
>
> Best regards
>
> On Thu, Jul 26, 2018 at 8:12 PM, Martin Jansa <martin.jansa@gmail.com>
> wrote:
>
>> It's not as simple as that in some cases, there are some components which
>> are pulled in 64bit version even when building lib32-foo-image.
>>
>> Some are easy to override from the config e.g.:
>> ROOTFS_PKGMANAGE = "${LIB32_PREFIX}opkg"
>> SPLASH = "${LIB32_PREFIX}psplash"
>>
>> but to prevent building e.g. syslinux in 64bit version is a bit more
>> tricky.
>>
>> syslinux.bbclass was fixed long time ago:
>> commit c8dc421ea18bb7a810501ab6d07efa9c8f6d6eb9
>> Author: Ming Liu <ming.liu@windriver.com>
>> Date:   Thu Jun 19 16:42:58 2014 +0800
>>
>>     syslinux.bbclass: Ensure MLPREFIX is applied to depends flag
>>
>>     Add MLPREFIX to depends flag to ensure the correct syslinux is
>>     dependended upon.
>>
>> -do_bootimg[depends] += "syslinux:do_populate_sysroot \
>> +do_bootimg[depends] += "${MLPREFIX}syslinux:do_populate_sysroot \
>>
>> but wic still depends on syslinux without MLPREFIX:
>>
>> meta/conf/machine/qemux86-64.conf:do_image_wic[depends] +=
>> "syslinux:do_populate_sysroot syslinux-native:do_populate_sysroot
>> mtools-native:do_populate_sysroot dosfstools-nat...
>> meta/conf/machine/qemux86.conf:do_image_wic[depends] +=
>> "syslinux:do_populate_sysroot syslinux-native:do_populate_sysroot
>> mtools-native:do_populate_sysroot dosfstools-native...
>>
>> similarly opkg-utils and some other components are pulled in the
>> not-prefixed version even when building image with a prefix. I've
>> eventually got it working with morty (that it was really building only
>> couple 64bit recipes, mostly kernel and recipes providing external modules
>> and e.g. depmodwrapper-cross), but it's kind of shaky and error prone, I'll
>> send fixes for some of these issues, but as we're using morty it's more
>> complicated to find out what is still needed and what was resolved in newer
>> OE already.
>>
>> And there are the issues with allarch recipes mentioned in the other
>> multilib thread.
>>
>> Regards,
>>
>>
>> On Thu, Jul 26, 2018 at 5:59 PM Mark Hatle <mark.hatle@windriver.com>
>> wrote:
>>
>>> On 7/26/18 10:19 AM, Alexander Kanavin wrote:
>>> > 2018-07-26 14:56 GMT+02:00 Ayoub Zaki <ayoub.zaki@googlemail.com>:
>>> >> Is it possible to define a MACHINE configuration with a 64 Bit kernel
>>> and 32
>>> >> Bit user space ?
>>> >>
>>> >> The user space should not be using a  x32 ABI.
>>> >
>>> > I think (but I am not sure), that you can do it with multilib. Define
>>> > a configuration like this:
>>> >
>>> https://github.com/openembedded/openembedded-core/blob/master/meta-skeleton/conf/multilib-example.conf
>>> >
>>> > Then build lib32-core-image-minimal. That image should include only 32
>>> > bit user space, but the kernel will be 64 bit.
>>>
>>> Yes this is the typical approach.  Enable multilibs, and then build the
>>> image
>>> you you want with the approach multilib prefix.
>>>
>>> This works in any multilib configurations, 64-bit, 32-bit, x32, etc..
>>>
>>> --Mark
>>>
>>> > Alex
>>> >
>>>
>>> --
>>> _______________________________________________
>>> yocto mailing list
>>> yocto@yoctoproject.org
>>> https://lists.yoctoproject.org/listinfo/yocto
>>>
>>
>> --
>> _______________________________________________
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>>
>>
>

[-- Attachment #2: Type: text/html, Size: 11930 bytes --]

Re: Intel machine with 64 Bit kernel and 32 Bit user space

[Ayoub Zaki]

[-- Attachment #1: Type: text/plain, Size: 8210 bytes --]

Hi all,

I added to my image:  IMAGE_INSTALL_append = " lib32-glibc" and it solved
the build problem !

now I can build a mixed image (64 Bit kernel, 32 Bit) user space using
multilib :

$ MACHINE =mymachine bitbake lib32-my-image

Thank you all for your inputs.

best regards

On Fri, Jul 27, 2018 at 1:19 PM, Martin Jansa <martin.jansa@gmail.com>
wrote:

> Check with bitbake -g what's pulling gcc-runtime into the image, if your
> whole userspace should be 32bit, then lib32-gcc-runtime will be enough.
>
> My multilib builds contain only following 64bit builds:
> defaultpkgname  depmodwrapper-cross  linux-yocto  lttng-modules
> make-mod-scripts  qemuwrapper-cross  vboxguestdrivers
> the rest is 32bit
>
> On Fri, Jul 27, 2018 at 12:23 PM Ayoub Zaki <ayoub.zaki@googlemail.com>
> wrote:
>
>> Hello all,
>>
>> thanks for the suggestions: I tried the multilib concept of yocto but as
>> Martin already wrote is not that simple, my build is breaking during wic
>> image generation as follow:
>>
>> zaki@xps:/opt/build/poky/build$ MACHINE=nx bitbake  lib32-my-image
>> Loading cache: 100% |#############################
>> ############################################################
>> #######################################################################################|
>> Time: 0:00:00
>> Loaded 4968 entries from dependency cache.
>> NOTE: Resolving any missing task queue dependencies
>>
>> Build Configuration:
>> BB_VERSION           = "1.38.0"
>> BUILD_SYS            = "x86_64-linux"
>> NATIVELSBSTRING      = "universal"
>> TARGET_SYS           = "x86_64-poky-linux"
>> MACHINE              = "nx"
>> DISTRO               = "poky"
>> DISTRO_VERSION       = "V00.00.00.00+20180727100935"
>> TUNE_FEATURES        = "m64 core2"
>> TARGET_FPU           = ""
>> meta
>> meta-poky
>> meta-yocto-bsp       = "sumo:90f7edb32ac2500d93bb7ca5045a9d048f551223"
>> meta-intel           = "sumo:2430f73ee06f3315ebebe69899f1977f9a09e29f"
>> meta-oe
>> meta-networking
>> meta-webserver
>> meta-python          = "sumo:b0950aeff5b630256bb5e25ca15f4d59c115e7c1"
>>
>> Initialising tasks: 100% |#############################
>> ############################################################
>> ##################################################################################|
>> Time: 0:00:02
>> NOTE: Executing SetScene Tasks
>> NOTE: Executing RunQueue Tasks
>> WARNING: lib32-my-image-1.0-r0 do_rootfs: lib32-systemd.postinst returned
>> 1, marking as unpacked only, configuration required on target.
>> WARNING: lib32-my-image-1.0-r0 do_rootfs: Intentionally failing
>> postinstall scriptlets of ['lib32-systemd'] to defer them to first boot is
>> deprecated. Please place them into pkg_postinst_ontarget_${PN} ().
>> If deferring to first boot wasn't the intent, then scriptlet failure may
>> mean an issue in the recipe, or a regression elsewhere.
>> Details of the failure are in /opt/build/poky/build/tmp/
>> work/nx-pokymllib32-linux/lib32-my-image/1.0-r0/temp/log.do_rootfs.
>> WARNING: lib32-my-image-1.0-r0 do_rootfs: [log_check] lib32-my-image:
>> found 1 warning message in the logfile:
>> [log_check] WARNING: Intentionally failing postinstall scriptlets of
>> ['lib32-systemd'] to defer them to first boot is deprecated. Please place
>> them into pkg_postinst_ontarget_${PN} ().
>> ERROR: lib32-my-image-1.0-r0 do_image_wic: The file
>> /usr/share/gcc-7.3.0/python/libstdcxx/__init__.py is installed by both
>> lib32-gcc-runtime and gcc-runtime, aborting
>> ERROR: lib32-my-image-1.0-r0 do_image_wic: Function failed:
>> extend_recipe_sysroot
>> ERROR: Logfile of failure stored in: /opt/build/poky/build/tmp/
>> work/nx-pokymllib32-linux/lib32-my-image/1.0-r0/temp/
>> log.do_image_wic.16922
>> ERROR: Task (virtual:multilib:lib32:/opt/build/poky/meta-poky/recipes-
>> core/images/my-image.bb:do_image_wic) failed with exit code '1'
>> NOTE: Tasks Summary: Attempted 3460 tasks of which 3445 didn't need to be
>> rerun and 1 failed.
>>
>> Summary: 1 task failed:
>>   virtual:multilib:lib32:/opt/build/poky/meta-poky/recipes-
>> core/images/my-image.bb:do_image_wic
>> Summary: There were 3 WARNING messages shown.
>> Summary: There were 2 ERROR messages shown, returning a non-zero exit
>> code.
>>
>>
>> The ERROR: lib32-my-image-1.0-r0 do_image_wic: The file
>> /usr/share/gcc-7.3.0/python/libstdcxx/__init__.py is installed by both
>> lib32-gcc-runtime and gcc-runtime, aborting is not self-explanatory!
>>
>> gcc-runtime is anyway not part of the image ?!
>>
>> any suggestions ?
>>
>>
>> thank you
>>
>>
>> Best regards
>>
>> On Thu, Jul 26, 2018 at 8:12 PM, Martin Jansa <martin.jansa@gmail.com>
>> wrote:
>>
>>> It's not as simple as that in some cases, there are some components
>>> which are pulled in 64bit version even when building lib32-foo-image.
>>>
>>> Some are easy to override from the config e.g.:
>>> ROOTFS_PKGMANAGE = "${LIB32_PREFIX}opkg"
>>> SPLASH = "${LIB32_PREFIX}psplash"
>>>
>>> but to prevent building e.g. syslinux in 64bit version is a bit more
>>> tricky.
>>>
>>> syslinux.bbclass was fixed long time ago:
>>> commit c8dc421ea18bb7a810501ab6d07efa9c8f6d6eb9
>>> Author: Ming Liu <ming.liu@windriver.com>
>>> Date:   Thu Jun 19 16:42:58 2014 +0800
>>>
>>>     syslinux.bbclass: Ensure MLPREFIX is applied to depends flag
>>>
>>>     Add MLPREFIX to depends flag to ensure the correct syslinux is
>>>     dependended upon.
>>>
>>> -do_bootimg[depends] += "syslinux:do_populate_sysroot \
>>> +do_bootimg[depends] += "${MLPREFIX}syslinux:do_populate_sysroot \
>>>
>>> but wic still depends on syslinux without MLPREFIX:
>>>
>>> meta/conf/machine/qemux86-64.conf:do_image_wic[depends] +=
>>> "syslinux:do_populate_sysroot syslinux-native:do_populate_sysroot
>>> mtools-native:do_populate_sysroot dosfstools-nat...
>>> meta/conf/machine/qemux86.conf:do_image_wic[depends] +=
>>> "syslinux:do_populate_sysroot syslinux-native:do_populate_sysroot
>>> mtools-native:do_populate_sysroot dosfstools-native...
>>>
>>> similarly opkg-utils and some other components are pulled in the
>>> not-prefixed version even when building image with a prefix. I've
>>> eventually got it working with morty (that it was really building only
>>> couple 64bit recipes, mostly kernel and recipes providing external modules
>>> and e.g. depmodwrapper-cross), but it's kind of shaky and error prone, I'll
>>> send fixes for some of these issues, but as we're using morty it's more
>>> complicated to find out what is still needed and what was resolved in newer
>>> OE already.
>>>
>>> And there are the issues with allarch recipes mentioned in the other
>>> multilib thread.
>>>
>>> Regards,
>>>
>>>
>>> On Thu, Jul 26, 2018 at 5:59 PM Mark Hatle <mark.hatle@windriver.com>
>>> wrote:
>>>
>>>> On 7/26/18 10:19 AM, Alexander Kanavin wrote:
>>>> > 2018-07-26 14:56 GMT+02:00 Ayoub Zaki <ayoub.zaki@googlemail.com>:
>>>> >> Is it possible to define a MACHINE configuration with a 64 Bit
>>>> kernel and 32
>>>> >> Bit user space ?
>>>> >>
>>>> >> The user space should not be using a  x32 ABI.
>>>> >
>>>> > I think (but I am not sure), that you can do it with multilib. Define
>>>> > a configuration like this:
>>>> > https://github.com/openembedded/openembedded-core/blob/master/meta-
>>>> skeleton/conf/multilib-example.conf
>>>> >
>>>> > Then build lib32-core-image-minimal. That image should include only 32
>>>> > bit user space, but the kernel will be 64 bit.
>>>>
>>>> Yes this is the typical approach.  Enable multilibs, and then build the
>>>> image
>>>> you you want with the approach multilib prefix.
>>>>
>>>> This works in any multilib configurations, 64-bit, 32-bit, x32, etc..
>>>>
>>>> --Mark
>>>>
>>>> > Alex
>>>> >
>>>>
>>>> --
>>>> _______________________________________________
>>>> yocto mailing list
>>>> yocto@yoctoproject.org
>>>> https://lists.yoctoproject.org/listinfo/yocto
>>>>
>>>
>>> --
>>> _______________________________________________
>>> yocto mailing list
>>> yocto@yoctoproject.org
>>> https://lists.yoctoproject.org/listinfo/yocto
>>>
>>>
>>

[-- Attachment #2: Type: text/html, Size: 13058 bytes --]

Re: Intel machine with 64 Bit kernel and 32 Bit user space

[Ayoub Zaki]

[-- Attachment #1: Type: text/plain, Size: 8679 bytes --]

I just realized that SDK generation does not include the lib32 libraries !

I run for that :

$ MACHINE=my-machine bitbake -c pouplate_sdk my-image




On Mon, Jul 30, 2018 at 2:51 PM, Ayoub Zaki <ayoub.zaki@googlemail.com>
wrote:

> Hi all,
>
> I added to my image:  IMAGE_INSTALL_append = " lib32-glibc" and it solved
> the build problem !
>
> now I can build a mixed image (64 Bit kernel, 32 Bit) user space using
> multilib :
>
> $ MACHINE =mymachine bitbake lib32-my-image
>
> Thank you all for your inputs.
>
> best regards
>
> On Fri, Jul 27, 2018 at 1:19 PM, Martin Jansa <martin.jansa@gmail.com>
> wrote:
>
>> Check with bitbake -g what's pulling gcc-runtime into the image, if your
>> whole userspace should be 32bit, then lib32-gcc-runtime will be enough.
>>
>> My multilib builds contain only following 64bit builds:
>> defaultpkgname  depmodwrapper-cross  linux-yocto  lttng-modules
>> make-mod-scripts  qemuwrapper-cross  vboxguestdrivers
>> the rest is 32bit
>>
>> On Fri, Jul 27, 2018 at 12:23 PM Ayoub Zaki <ayoub.zaki@googlemail.com>
>> wrote:
>>
>>> Hello all,
>>>
>>> thanks for the suggestions: I tried the multilib concept of yocto but as
>>> Martin already wrote is not that simple, my build is breaking during wic
>>> image generation as follow:
>>>
>>> zaki@xps:/opt/build/poky/build$ MACHINE=nx bitbake  lib32-my-image
>>> Loading cache: 100% |#############################
>>> ############################################################
>>> #######################################################################################|
>>> Time: 0:00:00
>>> Loaded 4968 entries from dependency cache.
>>> NOTE: Resolving any missing task queue dependencies
>>>
>>> Build Configuration:
>>> BB_VERSION           = "1.38.0"
>>> BUILD_SYS            = "x86_64-linux"
>>> NATIVELSBSTRING      = "universal"
>>> TARGET_SYS           = "x86_64-poky-linux"
>>> MACHINE              = "nx"
>>> DISTRO               = "poky"
>>> DISTRO_VERSION       = "V00.00.00.00+20180727100935"
>>> TUNE_FEATURES        = "m64 core2"
>>> TARGET_FPU           = ""
>>> meta
>>> meta-poky
>>> meta-yocto-bsp       = "sumo:90f7edb32ac2500d93bb7ca5045a9d048f551223"
>>> meta-intel           = "sumo:2430f73ee06f3315ebebe69899f1977f9a09e29f"
>>> meta-oe
>>> meta-networking
>>> meta-webserver
>>> meta-python          = "sumo:b0950aeff5b630256bb5e25ca15f4d59c115e7c1"
>>>
>>> Initialising tasks: 100% |#############################
>>> ############################################################
>>> ##################################################################################|
>>> Time: 0:00:02
>>> NOTE: Executing SetScene Tasks
>>> NOTE: Executing RunQueue Tasks
>>> WARNING: lib32-my-image-1.0-r0 do_rootfs: lib32-systemd.postinst
>>> returned 1, marking as unpacked only, configuration required on target.
>>> WARNING: lib32-my-image-1.0-r0 do_rootfs: Intentionally failing
>>> postinstall scriptlets of ['lib32-systemd'] to defer them to first boot is
>>> deprecated. Please place them into pkg_postinst_ontarget_${PN} ().
>>> If deferring to first boot wasn't the intent, then scriptlet failure may
>>> mean an issue in the recipe, or a regression elsewhere.
>>> Details of the failure are in /opt/build/poky/build/tmp/work
>>> /nx-pokymllib32-linux/lib32-my-image/1.0-r0/temp/log.do_rootfs.
>>> WARNING: lib32-my-image-1.0-r0 do_rootfs: [log_check] lib32-my-image:
>>> found 1 warning message in the logfile:
>>> [log_check] WARNING: Intentionally failing postinstall scriptlets of
>>> ['lib32-systemd'] to defer them to first boot is deprecated. Please place
>>> them into pkg_postinst_ontarget_${PN} ().
>>> ERROR: lib32-my-image-1.0-r0 do_image_wic: The file
>>> /usr/share/gcc-7.3.0/python/libstdcxx/__init__.py is installed by both
>>> lib32-gcc-runtime and gcc-runtime, aborting
>>> ERROR: lib32-my-image-1.0-r0 do_image_wic: Function failed:
>>> extend_recipe_sysroot
>>> ERROR: Logfile of failure stored in: /opt/build/poky/build/tmp/work
>>> /nx-pokymllib32-linux/lib32-my-image/1.0-r0/temp/log.do_image_wic.16922
>>> ERROR: Task (virtual:multilib:lib32:/opt/build/poky/meta-poky/recipes-co
>>> re/images/my-image.bb:do_image_wic) failed with exit code '1'
>>> NOTE: Tasks Summary: Attempted 3460 tasks of which 3445 didn't need to
>>> be rerun and 1 failed.
>>>
>>> Summary: 1 task failed:
>>>   virtual:multilib:lib32:/opt/build/poky/meta-poky/recipes-cor
>>> e/images/my-image.bb:do_image_wic
>>> Summary: There were 3 WARNING messages shown.
>>> Summary: There were 2 ERROR messages shown, returning a non-zero exit
>>> code.
>>>
>>>
>>> The ERROR: lib32-my-image-1.0-r0 do_image_wic: The file
>>> /usr/share/gcc-7.3.0/python/libstdcxx/__init__.py is installed by both
>>> lib32-gcc-runtime and gcc-runtime, aborting is not self-explanatory!
>>>
>>> gcc-runtime is anyway not part of the image ?!
>>>
>>> any suggestions ?
>>>
>>>
>>> thank you
>>>
>>>
>>> Best regards
>>>
>>> On Thu, Jul 26, 2018 at 8:12 PM, Martin Jansa <martin.jansa@gmail.com>
>>> wrote:
>>>
>>>> It's not as simple as that in some cases, there are some components
>>>> which are pulled in 64bit version even when building lib32-foo-image.
>>>>
>>>> Some are easy to override from the config e.g.:
>>>> ROOTFS_PKGMANAGE = "${LIB32_PREFIX}opkg"
>>>> SPLASH = "${LIB32_PREFIX}psplash"
>>>>
>>>> but to prevent building e.g. syslinux in 64bit version is a bit more
>>>> tricky.
>>>>
>>>> syslinux.bbclass was fixed long time ago:
>>>> commit c8dc421ea18bb7a810501ab6d07efa9c8f6d6eb9
>>>> Author: Ming Liu <ming.liu@windriver.com>
>>>> Date:   Thu Jun 19 16:42:58 2014 +0800
>>>>
>>>>     syslinux.bbclass: Ensure MLPREFIX is applied to depends flag
>>>>
>>>>     Add MLPREFIX to depends flag to ensure the correct syslinux is
>>>>     dependended upon.
>>>>
>>>> -do_bootimg[depends] += "syslinux:do_populate_sysroot \
>>>> +do_bootimg[depends] += "${MLPREFIX}syslinux:do_populate_sysroot \
>>>>
>>>> but wic still depends on syslinux without MLPREFIX:
>>>>
>>>> meta/conf/machine/qemux86-64.conf:do_image_wic[depends] +=
>>>> "syslinux:do_populate_sysroot syslinux-native:do_populate_sysroot
>>>> mtools-native:do_populate_sysroot dosfstools-nat...
>>>> meta/conf/machine/qemux86.conf:do_image_wic[depends] +=
>>>> "syslinux:do_populate_sysroot syslinux-native:do_populate_sysroot
>>>> mtools-native:do_populate_sysroot dosfstools-native...
>>>>
>>>> similarly opkg-utils and some other components are pulled in the
>>>> not-prefixed version even when building image with a prefix. I've
>>>> eventually got it working with morty (that it was really building only
>>>> couple 64bit recipes, mostly kernel and recipes providing external modules
>>>> and e.g. depmodwrapper-cross), but it's kind of shaky and error prone, I'll
>>>> send fixes for some of these issues, but as we're using morty it's more
>>>> complicated to find out what is still needed and what was resolved in newer
>>>> OE already.
>>>>
>>>> And there are the issues with allarch recipes mentioned in the other
>>>> multilib thread.
>>>>
>>>> Regards,
>>>>
>>>>
>>>> On Thu, Jul 26, 2018 at 5:59 PM Mark Hatle <mark.hatle@windriver.com>
>>>> wrote:
>>>>
>>>>> On 7/26/18 10:19 AM, Alexander Kanavin wrote:
>>>>> > 2018-07-26 14:56 GMT+02:00 Ayoub Zaki <ayoub.zaki@googlemail.com>:
>>>>> >> Is it possible to define a MACHINE configuration with a 64 Bit
>>>>> kernel and 32
>>>>> >> Bit user space ?
>>>>> >>
>>>>> >> The user space should not be using a  x32 ABI.
>>>>> >
>>>>> > I think (but I am not sure), that you can do it with multilib. Define
>>>>> > a configuration like this:
>>>>> > https://github.com/openembedded/openembedded-core/blob/
>>>>> master/meta-skeleton/conf/multilib-example.conf
>>>>> >
>>>>> > Then build lib32-core-image-minimal. That image should include only
>>>>> 32
>>>>> > bit user space, but the kernel will be 64 bit.
>>>>>
>>>>> Yes this is the typical approach.  Enable multilibs, and then build
>>>>> the image
>>>>> you you want with the approach multilib prefix.
>>>>>
>>>>> This works in any multilib configurations, 64-bit, 32-bit, x32, etc..
>>>>>
>>>>> --Mark
>>>>>
>>>>> > Alex
>>>>> >
>>>>>
>>>>> --
>>>>> _______________________________________________
>>>>> yocto mailing list
>>>>> yocto@yoctoproject.org
>>>>> https://lists.yoctoproject.org/listinfo/yocto
>>>>>
>>>>
>>>> --
>>>> _______________________________________________
>>>> yocto mailing list
>>>> yocto@yoctoproject.org
>>>> https://lists.yoctoproject.org/listinfo/yocto
>>>>
>>>>
>>>
>

[-- Attachment #2: Type: text/html, Size: 13792 bytes --]