/usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-ani.la (requires /usr/lib64/libgdk_pixbuf-2.0.la) /usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-bmp.la (requires /usr/lib64/libgdk_pixbuf-2.0.la) /usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-gif.la (requires /usr/lib64/libgdk_pixbuf-2.0.la) /usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-icns.la (requires /usr/lib64/libgdk_pixbuf-2.0.la) /usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-ico.la (requires /usr/lib64/libgdk_pixbuf-2.0.la) /usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-jasper.la (requires /usr/lib64/libgdk_pixbuf-2.0.la) /usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-jpeg.la (requires /usr/lib64/libgdk_pixbuf-2.0.la) /usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-pcx.la (requires /usr/lib64/libgdk_pixbuf-2.0.la) /usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-png.la (requires /usr/lib64/libgdk_pixbuf-2.0.la) /usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-pnm.la (requires /usr/lib64/libgdk_pixbuf-2.0.la) /usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-qtif.la (requires /usr/lib64/libgdk_pixbuf-2.0.la) /usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-ras.la (requires /usr/lib64/libgdk_pixbuf-2.0.la) /usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-tga.la (requires /usr/lib64/libgdk_pixbuf-2.0.la) /usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-tiff.la (requires /usr/lib64/libgdk_pixbuf-2.0.la) /usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-wbmp.la (requires /usr/lib64/libgdk_pixbuf-2.0.la) /usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-xbm.la (requires /usr/lib64/libgdk_pixbuf-2.0.la) /usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-xpm.la (requires /usr/lib64/libgdk_pixbuf-2.0.la) So these .la files inside /usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders/ all depend on non-existent .la files from /usr/lib64/ and hence are all broken. This confuses package managers that try to fix linkage.
They are removed in my case: * Removing unnecessary /usr/lib64/libgdk_pixbuf_xlib-2.0.la (no static archive) * Removing unnecessary /usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-qtif.la (no static archive) * Removing unnecessary /usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-pcx.la (no static archive) * Removing unnecessary /usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-icns.la (no static archive) * Removing unnecessary /usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-tga.la (no static archive) * Removing unnecessary /usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-xbm.la (no static archive) * Removing unnecessary /usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-xpm.la (no static archive) * Removing unnecessary /usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-tiff.la (no static archive) * Removing unnecessary /usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-ras.la (no static archive) * Removing unnecessary /usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-pnm.la (no static archive) * Removing unnecessary /usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-jpeg.la (no static archive) * Removing unnecessary /usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-ani.la (no static archive) * Removing unnecessary /usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-ico.la (no static archive) * Removing unnecessary /usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-gif.la (no static archive) * Removing unnecessary /usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-wbmp.la (no static archive) * Removing unnecessary /usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-bmp.la (no static archive) * Removing unnecessary /usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-png.la (no static archive) * Removing unnecessary /usr/lib64/libgdk_pixbuf-2.0.la (no static archive) Maybe providing full build.log will show what is occurring :/
I hacked the eclass to do if [[ ${reason} ]]; then einfo "Removing unnecessary ${f#${D%/}} (${reason})" queue+=( "${f}" ) else einfo "Not removing ${f#${D%/}} (${reason})" fi output: * Not removing /usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-png.la () * Not removing /usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-xbm.la () * Not removing /usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-wbmp.la () * Not removing /usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-tga.la () * Not removing /usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-tiff.la () * Not removing /usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-qtif.la () * Not removing /usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-xpm.la () * Not removing /usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-bmp.la () * Not removing /usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-pnm.la () * Not removing /usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-ani.la () * Not removing /usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-jpeg.la () * Not removing /usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-ico.la () * Not removing /usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-ras.la () * Not removing /usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-gif.la () * Not removing /usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-icns.la () * Not removing /usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-jasper.la () * Not removing /usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-pcx.la () * Removing unnecessary /usr/lib64/libgdk_pixbuf_xlib-2.0.la (no static archive) * Removing unnecessary /usr/lib64/libgdk_pixbuf-2.0.la (no static archive)
Err... the first think I checked was if I had the files, as that wasn't the case I reemerged the package to try to see if they were removed by eclass or not :/ $ ls -l /usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders/ total 308 -rwxr-xr-x 1 root root 18600 jul 27 19:09 libpixbufloader-ani.so -rwxr-xr-x 1 root root 18504 jul 27 19:09 libpixbufloader-bmp.so -rwxr-xr-x 1 root root 26936 jul 27 19:09 libpixbufloader-gif.so -rwxr-xr-x 1 root root 10296 jul 27 19:09 libpixbufloader-icns.so -rwxr-xr-x 1 root root 18576 jul 27 19:09 libpixbufloader-ico.so -rwxr-xr-x 1 root root 22872 jul 27 19:09 libpixbufloader-jpeg.so -rwxr-xr-x 1 root root 14280 jul 27 19:09 libpixbufloader-pcx.so -rwxr-xr-x 1 root root 22936 jul 27 19:09 libpixbufloader-png.so -rwxr-xr-x 1 root root 14400 jul 27 19:09 libpixbufloader-pnm.so -rwxr-xr-x 1 root root 14400 jul 27 19:09 libpixbufloader-qtif.so -rwxr-xr-x 1 root root 10200 jul 27 19:09 libpixbufloader-ras.so -rwxr-xr-x 1 root root 10312 jun 21 21:48 libpixbufloader-svg.so -rwxr-xr-x 1 root root 14288 jul 27 19:09 libpixbufloader-tga.so -rwxr-xr-x 1 root root 14512 jul 27 19:09 libpixbufloader-tiff.so -rwxr-xr-x 1 root root 10184 jul 27 19:09 libpixbufloader-wbmp.so -rwxr-xr-x 1 root root 14408 jul 27 19:09 libpixbufloader-xbm.so -rwxr-xr-x 1 root root 26824 jul 27 19:09 libpixbufloader-xpm.so
I, too, can't find this la files. Since we don't have a "static-libs" USE flag on this package, there is no reason for them to be installed. $ eix -c gdk-pixbuf [I] x11-libs/gdk-pixbuf (2.30.8(2)@01/07/2014): Image loading library for GTK+ $ qlist gdk-pixbuf |egrep "\.(so|la)$" /usr/lib64/libgdk_pixbuf_xlib-2.0.so /usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-qtif.so /usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-icns.so /usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-pcx.so /usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-jpeg.so /usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-tga.so /usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-gif.so /usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-pnm.so /usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-png.so /usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-xbm.so /usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-ani.so /usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-xpm.so /usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-wbmp.so /usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-ras.so /usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-ico.so /usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-bmp.so /usr/lib64/libgdk_pixbuf-2.0.so I also rebuilt the package just in case, but same outcome. Could you try from a clean tree and provide emerge --info and build.log ?
(In reply to Gilles Dartiguelongue from comment #4) > > Could you try from a clean tree and provide emerge --info and build.log ? What do you mean by a "clean tree"? Also, I don't use portage.
Well, unaltered ebuilds and eclasses I guess.
Issue exist for Paludis users at least. Presumably problem with gnome2_src_install function in gnome2.eclass, as prev. version without it (gdk-pixbuf-2.30.7-r1.ebuild) works fine. Simple changing condition from "if has ${EAPI:-0} 0 1 2 3 4" to "if has ${EAPI:-0} 0 1 2 3 4 5" (note last digit) solves the problem. It seems natural as ebuild contains EAPI="5".
For eapi5 we simply rely on eutils.eclass and, in this concrete case, it's running "prune_libtool_files" without any arguments @mgorny, are you still maintaining this in eutils.eclass or is this now handled by base-system
Provide *full build log* and eclass debug log.
Ok, found the bug. Index: eutils.eclass =================================================================== RCS file: /var/cvsroot/gentoo-x86/eclass/eutils.eclass,v retrieving revision 1.441 diff -u -B -r1.441 eutils.eclass --- eutils.eclass 30 Dec 2014 07:24:52 -0000 1.441 +++ eutils.eclass 14 Jan 2015 22:49:07 -0000 @@ -1578,7 +1578,7 @@ fi [[ ${f} != ${archivefile} ]] || die 'regex sanity check failed' - local reason pkgconfig_scanned + local reason= pkgconfig_scanned= local snotlink=$(sed -n -e 's:^shouldnotlink=::p' "${f}") if [[ ${snotlink} == yes ]]; then All hail the mighty bash, the most stupid pseudo-programming shellscript ever invented, with its dumb, illogical and completely non-sense pseudo-local scopes.
lets assume it's fixed then
actually it's not fixed... this one gets removed: /usr/lib64/libgdk_pixbuf-2.0.la this one not: /usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-ani.la looking at /usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-ani.la we see > dependency_libs=' /usr/lib64/libgdk_pixbuf-2.0.la -lgmodule-2.0 -lgio-2.0 -lgobject-2.0 -lglib-2.0 -lpng16 -lm' so the algorithm in prune_libtool_files doesn't seem to catch this case
It's a module loader .la file. dependency_libs is irrelevant since it is used purely to read .so name.
Created attachment 394294 [details] gdk-pixbuf build log What I do: 1. cave sync 2. cave resolve -x1 x11-libs/gdk-pixbuf >gdk-pixbuf.log 2>&1
(In reply to Michał Górny from comment #13) > It's a module loader .la file. dependency_libs is irrelevant since it is > used purely to read .so name. If dependency_libs is irrelevant, then it shouldn't be set... or we should remove all .la files consistently.
(In reply to Julian Ospald (hasufell) from comment #15) > (In reply to Michał Górny from comment #13) > > It's a module loader .la file. dependency_libs is irrelevant since it is > > used purely to read .so name. > > If dependency_libs is irrelevant, then it shouldn't be set... or we should > remove all .la files consistently. +1 . or sed la files to remove the dependcy_libs line if these need to be installed . or prepend a hash to this line . or change the way cave fix-linkage works (if there is a way to distinct .la files where dependency_libs line is needed from those .la files with irrelevant ones..) either way, currently stray .la files with dangling links to .la files never been installed make using fix-linkage commands a mess. it's not just gdk-pixbuf that is affected by this type of bug, e.g. bug 537418, bug 537470, bug 537476 have similar error patterns.
Let's get this clear: 1. The files aren't broken. They are created by libtool as designed. 2. The files are the same across all PMs now. It's just paludis that does this kind of rebuild magic on top of them. 3. The files are most likely useless. But that's irrelevant to PM or whatever. It's your call to decide if you can pass --modules to prune_libtool_files or not.
(In reply to Michał Górny from comment #17) [...] > 3. The files are most likely useless. But that's irrelevant to PM or > whatever. It's your call to decide if you can pass --modules to > prune_libtool_files or not. We are not passing "--modules" because no .la files are installed even without that option on portage (then, it's a bit hard to figure out that we need to pass a more "aggresive" option to clean them on other setups)
(In reply to Pacho Ramos from comment #18) > (In reply to Michał Górny from comment #17) > [...] > > 3. The files are most likely useless. But that's irrelevant to PM or > > whatever. It's your call to decide if you can pass --modules to > > prune_libtool_files or not. > > We are not passing "--modules" because no .la files are installed even > without that option on portage (then, it's a bit hard to figure out that we > need to pass a more "aggresive" option to clean them on other setups) Oh nice, just re-emerged and they are now installed !?!? I guess the previous fix to the eclass make it behave consistently for all of us + 24 Jan 2015; Pacho Ramos <pacho@gentoo.org> + -files/gdk-pixbuf-2.28.0-string_h.patch, -gdk-pixbuf-2.30.7-r1.ebuild, + -gdk-pixbuf-2.30.7.ebuild, gdk-pixbuf-2.30.8.ebuild: + Really prune all .la files (#518334), drop old +
