Bug 4408

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.

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.

Moving to 1.5 after discussion with Saul/Richard/Mark.

I still don't have a viable fix for this. At this point it's probably going to be a 1.6 task.

(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.

Mark it as works for me, please see my previous comments.

I understand what happened now, reopen it, and send patches to oe-core mailing list.

Merged into master:
http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=eb7b1a58ceaab7fde4dc954eb4df4247d6c7c6d8

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