Summary: | x11-libs/gdk-pixbuf-2.36.11: gdk-pixbuf-2.0/2.10.0/loaders.cache not found in merging stage | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Tom-Steve Watzke <tswatzke> |
Component: | Current packages | Assignee: | Gentoo Linux Gnome Desktop Team <gnome> |
Status: | UNCONFIRMED --- | ||
Severity: | normal | CC: | ecyoung, herrtimson, jarausch, jstein, perfect007gentleman, water.devil |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
gdk-pixbuf-2.36.11 build.log
LC_ALL=C build.log gdk-pixbuf-2.36.11.ebuild ... fixed compressed build log |
Description
Tom-Steve Watzke
2018-01-05 07:48:32 UTC
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. |