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

Ayoub Zaki ayoub.zaki at googlemail.com
Mon Jul 30 06:46:18 PDT 2018 

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 at 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 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-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 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/db9df9eb/attachment-0001.html>

More information about the yocto mailing list