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.z...@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.ja...@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.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-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.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