4408 2013-04-24 10:59:13 +0000 multilib: rpm does not install all dependencies 2015-11-11 12:15:26 +0000 1 1 7 Build System, Metadata & Runtime OE-Core core 1.5 x86 Multiple VERIFIED FIXED Medium normal 2.0 1 laurentiu.palcu liezhi.yang bluelightning bogdanx.a.voiculescu jessica.zhang liezhi.yang meta.mr.watcher meta.watcher cristina-danielax.agurida --- --- No (bug/feature does not impact docs) oldest_to_newest 32575 0 laurentiu.palcu 2013-04-24 10:59:13 +0000 Problem description: lib32 dependencies are not all installed into the final image. Latest master commit tested: 361d686408b9a0b2ab2f1caf2b74adfe1ad1020c Steps to reproduce: 1. Add the following to your local.conf: MACHINE ??= "qemux86" PACKAGE_CLASSES ?= "package_rpm" require conf/multilib.conf MULTILIBS = "multilib:lib32" DEFAULTTUNE_virtclass-multilib-lib32 = "x86" IMAGE_INSTALL_append = " lib32-gtk+" 2. bitbake core-image-sato Expected result: * all lib32-gtk+ dependencies should end up on the final image (for example: lib32-gdk-pixbuf-loader-*) Actual result: * lib32-gdk-pixbuf-loader-* packages are not in the final image Notes: * if you change PACKAGE_CLASSES ?= "package_ipk" and repeat step 2, all the packages are properly installed to the final image; 32585 1 bluelightning 2013-04-24 14:54:20 +0000 So this is an issue with RRECOMMENDS; I noticed the same thing recently with RDEPENDS when building apache2 from meta-webserver in a lib32 multilib configuration - lib32-libgcc wasn't installed on the target when lib32-apache2 was installed. 32961 2 bluelightning 2013-05-08 16:21:42 +0000 Some further info - with my above test case i.e. lib32-apache2 and libgcc, the dependency as far as the RPM spec file goes ends up being libgcc1 for both apache2 and lib32-apache2, so you get the 64-bit version of libgcc1 installed in both cases which is not correct. For a normal shared library dependency, rpmdeps adds FILERDEPENDS that include/exclude the word size e.g. "(64bit)" thus ensuring the correct package gets installed, however this is a manually added RDEPENDS and thus those are not present. 33114 3 bluelightning 2013-05-16 13:32:13 +0000 Moving to 1.5 after discussion with Saul/Richard/Mark. 36683 4 bluelightning 2013-09-13 13:59:52 +0000 I still don't have a viable fix for this. At this point it's probably going to be a 1.6 task. 52063 5 liezhi.yang 2015-07-01 06:31:35 +0000 (In reply to comment #2) > Some further info - with my above test case i.e. lib32-apache2 and libgcc, > the dependency as far as the RPM spec file goes ends up being libgcc1 for > both apache2 and lib32-apache2, so you get the 64-bit version of libgcc1 > installed in both cases which is not correct. For a normal shared library > dependency, rpmdeps adds FILERDEPENDS that include/exclude the word size > e.g. "(64bit)" thus ensuring the correct package gets installed, however > this is a manually added RDEPENDS and thus those are not present. After more investigations: 1) I think that the mulitlib like the following one doesn't make any sense since the bsp is 32 bit, and the multilib is also 32 bit: MACHINE ??= "qemux86" PACKAGE_CLASSES ?= "package_rpm" require conf/multilib.conf MULTILIBS = "multilib:lib32" DEFAULTTUNE_virtclass-multilib-lib32 = "x86" IMAGE_INSTALL_append = " lib32-gtk+" The rpm backend can generate the rootfs, but the ipk can't, and there would be such errors: Multilib check error: duplicate files /buildarea/lyang1/t_clutter/tmp/work/qemux86-poky-linux/core-image-minimal/1.0-r0/multilib/lib32/lib/libz.so.1 /buildarea/lyang1/t_clutter/tmp/work/qemux86-poky-linux/core-image-minimal/1.0-r0/rootfs/lib/libz.so.1 is not the same 2) I think that the supported multilib should be something like: require conf/multilib.conf MULTILIBS = "multilib:lib32" DEFAULTTUNE_virtclass-multilib-lib32 = "x86" When bitbake core-image-sato, only the libgcc1.core2_64.rpm would be installed by default since no one depends on libgcc1.lib32_x86.rpm, In Paul's usecase, I think that lib32-apache doesn't depend on it, the one depends on libgcc1.lib32_x86.rpm is the package like lib32-libproxy, so if: IMAGE_INSTALL_append = " lib32-libproxy" Then libgcc1.lib32_x86.rpm would be installed (and also libgcc1.core2_64.rpm), so I think that there isn't anything wrong, or maybe it has been fixed in 1.9. 52064 6 liezhi.yang 2015-07-01 06:32:34 +0000 Mark it as works for me, please see my previous comments. 54126 7 liezhi.yang 2015-09-16 01:59:42 +0000 I understand what happened now, reopen it, and send patches to oe-core mailing list. 54723 8 liezhi.yang 2015-09-28 14:03:12 +0000 Merged into master: http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=eb7b1a58ceaab7fde4dc954eb4df4247d6c7c6d8 56380 9 cristina-danielax.agurida 2015-11-11 12:15:26 +0000 Verified on master: fc45deac89ef63ca1c44e763c38ced7dfd72cbe1 root@qemux86:~# find / -name "*pixbuf*" 2>/dev/null /usr/share/locale/en_GB/LC_MESSAGES/gdk-pixbuf.mo /usr/lib/libgdk_pixbuf-2.0.so.0 /usr/lib/libgdk_pixbuf-2.0.so.0.3000.8 /usr/lib/gstreamer-1.0/libgstgdkpixbuf.so /usr/lib/gdk-pixbuf-2.0 /usr/lib/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-jpeg.so /usr/lib/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-gif.so /usr/lib/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-xpm.so /usr/lib/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-png.so /usr/lib/gdk-pixbuf-2.0/gdk-pixbuf-query-loaders