[yocto] Intel machine with 64 Bit kernel and 32 Bit user space

Ayoub Zaki ayoub.zaki at googlemail.com
Mon Jul 30 05:51:12 PDT 2018 

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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at yoctoproject.org
>>>> https://lists.yoctoproject.org/listinfo/yocto
>>>>
>>>
>>> --
>>> _______________________________________________
>>> yocto mailing list
>>> yocto at yoctoproject.org
>>> https://lists.yoctoproject.org/listinfo/yocto
>>>
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20180730/eec9b342/attachment-0001.html>

More information about the yocto mailing list