>>> Installing (1 of 1) x11-libs/gdk-pixbuf-2.36.11::gentoo * checking 81 files for package collisions >>> Merging x11-libs/gdk-pixbuf-2.36.11 to / * abi_x86_32.x86: running multilib_pkg_preinst cp: reguläre Datei '/var/tmp/portage/x11-libs/gdk-pixbuf-2.36.11/image//usr/lib32/gdk-pixbuf-2.0/2.10.0/loaders.cache' kann nicht angelegt werden: Datei oder Verzeichnis nicht gefunden * ERROR: x11-libs/gdk-pixbuf-2.36.11::gentoo failed (preinst phase): * (no error message) * * Call stack: * ebuild.sh, line 124: Called pkg_preinst * environment, line 3618: Called multilib_foreach_abi 'multilib_pkg_preinst' * environment, line 3253: Called multibuild_foreach_variant '_multilib_multibuild_wrapper' 'multilib_pkg_preinst' * environment, line 2931: Called _multibuild_run '_multilib_multibuild_wrapper' 'multilib_pkg_preinst' * environment, line 2929: Called _multilib_multibuild_wrapper 'multilib_pkg_preinst' * environment, line 550: Called multilib_pkg_preinst * environment, line 3613: Called die * The specific snippet of code: * cp "${EROOT}"${cache} "${ED}"/${cache} || die; The loaders.cache cannot be found anywhere in the ${EROOT} directory. In the previous version 2.36.10-r2 all cache files are there. If they are not necessary the lines in the ebuild should be removed. I also could have done this, but I am not sure if they are still needed, i.e. the cache files.
Thank you for the report. Please *attach* the logfiles, https://wiki.gentoo.org/wiki/Attach_the_logs_to_the_bug_ticket and reopen this ticket (Status:unconfirmed). Please remember to set LANG=C Why do you think the bug is in the component "eclasses"?
Created attachment 513852 [details] gdk-pixbuf-2.36.11 build.log
Created attachment 513854 [details] LC_ALL=C build.log
I just set LC_ALL=C and attached a no-color build.log. As you can see the loaders.cache cannot be found: cp: cannot create regular file '/var/tmp/portage/x11-libs/gdk-pixbuf-2.36.11/image//usr/lib32/gdk-pixbuf-2.0/2.10.0/loaders.cache': No such file or directory
Is there a workaround? I have the same issues with 2.36.11 and 2.36.10-r2! Many thanks
Created attachment 515310 [details] gdk-pixbuf-2.36.11.ebuild ... fixed I finally found the issue. The caches could not be copied over to the image, because the directory to be copied in, does not exist. Therefore I fixed the ebuild and added: mkdir -p "${ED}/usr/$(get_libdir)/${PN}-2.0/2.10.0"
confirm
*** Bug 653026 has been marked as a duplicate of this bug. ***
(In reply to Tom-Steve Watzke from comment #6) > Created attachment 515310 [details] > gdk-pixbuf-2.36.11.ebuild ... fixed > > I finally found the issue. > The caches could not be copied over to the image, > because the directory to be copied in, does not exist. > > Therefore I fixed the ebuild and added: > > mkdir -p "${ED}/usr/$(get_libdir)/${PN}-2.0/2.10.0" With that modified ebuild I can install gdk-pixbuf BUT many applications are broken (e.g. gimp, many browser when trying to save and image, etc) One gets Could not load a pixbuf from icon theme. This may indicate that pixbuf loaders or the mime database could not be found.
It's because your dev-libs/glib version is lacking gmodule support. If gdk-pixbuf's build cannot detect a working glib with gmodule support, it won't build the libpixbufloader-* files. If no libpixbufloader-* files are built, generation of loaders.cache will fail (and so then can't be copied because it doesn't exist). Here are the offending parts from your build.log's ./configure: checking for GLIB - version >= 2.48.0... yes (version 2.54.0) checking whether to build gmodulized gdk-pixbuf... yes checking whether dynamic modules work... no The lack of gmodule support is a bug in >=dev-libs/glib-2.54 when using the new Meson build system instead of sticking with the proven to work autotools build system. So, not strictly a gdk-pixbuf bug but affected by the way >=dev-libs/glib-2.54 can be mis-built (and not in main tree yet).
So is this bug essentially INVALID or gnome-overlay only? Or should we handle something about potentially missing gmodule support in some situations (perhaps some prefix systems)? Main tree glib-2.58.2 is still using autotools; I don't think I will convert it to meson in main tree before 2.59/2.60 series, and I'd suspect it's fine for meson in those versions by now..
I think that this is a problem for cross compiling, isn't it?
So you are saying that we need to have the branch that has touch "${ED}"/${cache} || die preceded with an appropriate mkdir -p call for that valid use case of cross-compiling (as opposed to meson bugs). OK, will need to think about it and probably do.
Created attachment 562390 [details] compressed build log This is my build log from trying to cross-emerge from amd64 host to armv7 target. I think it's the same bug? It's a dependency of gtk+, unfortunatley.
I think the cross compile bug I suffer from is a different one, because its not about cache generation but the compilation of the binary itself, which is supposed to load the cache.
