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.z...@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.ja...@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....@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.ha...@windriver.com> >> wrote: >> >>> On 7/26/18 10:19 AM, Alexander Kanavin wrote: >>> > 2018-07-26 14:56 GMT+02:00 Ayoub Zaki <ayoub.z...@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 >> >> >
-- _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto