app-emulation/emul-linux-x86-xlibs-20091226 needs to depend on app-emulation/emul-linux-x86-gtklibs-20091226. xlibs installs (at the very least) a broken libcairo because libpixman-1.so isn't provided by earlier versions of gtklibs.
libcairo is also provided by emul-linux-x86-gtklibs. emul-linux-x86-xlibs shouldn't provide it and, in my case, it doesn't: $ equery files emul-linux-x86-xlibs |grep cairo $ $ equery files emul-linux-x86-gtklibs |grep cairo /usr/lib32/libcairo.so /usr/lib32/libcairo.so.2 /usr/lib32/libcairo.so.2.10800.8 /usr/lib32/libpangocairo-1.0.so /usr/lib32/libpangocairo-1.0.so.0 /usr/lib32/libpangocairo-1.0.so.0.2400.5 $ equery files emul-linux-x86-gtklibs |grep pixman /usr/lib32/libpixman-1.so /usr/lib32/libpixman-1.so.0 /usr/lib32/libpixman-1.so.0.17.2
Earlier today, I upgraded gtklibs (which fixed the problem), so I just downgraded them in an attempt to reproduce the problem and it didn't come back... so since I can't reproduce it, i'm closing the ticket as invalid. Sorry for wasting your time.
No problem :-)
So I was able to reproduce my problem, and I don't know what I was smoking when I first opened this bug, but I've fixed the description to describe the real problem. app-emulation/emul-linux-x86-gtklibs-20081109 (with app-emulation/emul-linux-x86-xlibs-20091226). # ldd /usr/lib32/libcairo.so linux-gate.so.1 => (0xf7709000) libfreetype.so.6 => /usr/lib32/libfreetype.so.6 (0xf7604000) libz.so.1 => /lib32/libz.so.1 (0xf75f0000) libfontconfig.so.1 => /usr/lib32/libfontconfig.so.1 (0xf75c4000) libpng12.so.0 => /usr/lib32/libpng12.so.0 (0xf75a0000) libXrender.so.1 => /usr/lib32/libXrender.so.1 (0xf7595000) libX11.so.6 => /usr/lib32/libX11.so.6 (0xf747b000) libpixman-1.so.0 => not found libm.so.6 => /lib32/libm.so.6 (0xf7455000) libc.so.6 => /lib32/libc.so.6 (0xf730f000) libexpat.so.1 => /usr/lib32/libexpat.so.1 (0xf72e8000) libxcb.so.1 => /usr/lib32/libxcb.so.1 (0xf72cf000) libXau.so.6 => /usr/lib32/libXau.so.6 (0xf72cb000) libXdmcp.so.6 => /usr/lib32/libXdmcp.so.6 (0xf72c5000) libdl.so.2 => /lib32/libdl.so.2 (0xf72c1000) /lib/ld-linux.so.2 (0xf770a000) My assumption is that the old version of xlibs had libpixman, which has subsequently been moved into gtklibs... but I haven't tested that. If that's the case, app-emulation/emul-linux-x86-gtklibs-20091226 just needs to depend on app-emulation/emul-linux-x86-xlibs-20091226
ahem, I mean app-emulation/emul-linux-x86-gtklibs-20081109 needs to depend on <=app-emulation/emul-linux-x86-xlibs-20091226
I'm posting as I think this issue is affecting my Acroread:- $ acroread /opt/Adobe/Reader9/Reader/intellinux/bin/acroread: error while loading shared libraries: libpixman-1.so.0: cannot open shared object file: No such file or directory # equery files emul-linux-x86-gtklibs |grep cairo /usr/lib32/libcairo.so /usr/lib32/libcairo.so.2 /usr/lib32/libcairo.so.2.17.5 /usr/lib32/libpangocairo-1.0.so /usr/lib32/libpangocairo-1.0.so.0 /usr/lib32/libpangocairo-1.0.so.0.2002.3 # equery files emul-linux-x86-gtklibs|grep pixman # equery files emul-linux-x86-xlibs |grep cairo # ldd /usr/lib32/libcairo.so linux-gate.so.1 => (0xf7ee8000) libfreetype.so.6 => /usr/lib32/libfreetype.so.6 (0xf7de1000) libz.so.1 => /lib32/libz.so.1 (0xf7dcd000) libfontconfig.so.1 => /usr/lib32/libfontconfig.so.1 (0xf7da1000) libpng12.so.0 => /usr/lib32/libpng12.so.0 (0xf7d7d000) libXrender.so.1 => /usr/lib32/libXrender.so.1 (0xf7d72000) libX11.so.6 => /usr/lib32/libX11.so.6 (0xf7c58000) libpixman-1.so.0 => not found libm.so.6 => /lib32/libm.so.6 (0xf7c31000) libc.so.6 => /lib32/libc.so.6 (0xf7ac6000) libexpat.so.1 => /usr/lib32/libexpat.so.1 (0xf7a9f000) libxcb.so.1 => /usr/lib32/libxcb.so.1 (0xf7a86000) libXau.so.6 => /usr/lib32/libXau.so.6 (0xf7a82000) libXdmcp.so.6 => /usr/lib32/libXdmcp.so.6 (0xf7a7c000) libdl.so.2 => /lib32/libdl.so.2 (0xf7a78000) /lib/ld-linux.so.2 (0xf7ee9000)
To expand, I've recently recompiled my system, and a subsequent revdep-rebuild, that I didn't expect to find anything due to everything having just been recompiled, gives the following (which needless to say, doesn't fix the problem...): # revdep-rebuild * Configuring search environment for revdep-rebuild * Checking reverse dependencies * Packages containing binaries and libraries broken by a package update * will be emerged. * Collecting system binaries and libraries * Generated new 1_files.rr * Collecting complete LD_LIBRARY_PATH * Generated new 2_ldpath.rr * Checking dynamic linking consistency [ 34% ] * broken /usr/lib32/libcairo.so.2.17.5 (requires libpixman-1.so.0) [ 100% ] * Generated new 3_broken.rr * Assigning files to packages * /usr/lib32/libcairo.so.2.17.5 -> app-emulation/emul-linux-x86-gtklibs * Generated new 4_raw.rr and 4_owners.rr * Cleaning list of packages to rebuild * Generated new 4_pkgs.rr * Assigning packages to ebuilds * Generated new 4_ebuilds.rr * Evaluating package order * Generated new 5_order.rr * All prepared. Starting rebuild emerge --oneshot app-emulation/emul-linux-x86-gtklibs:0 ...^C
This problem occurs because you are mixing stable and testing versions, you must install the same version for all emul packages, or breakages like this will occur again. I have to think about moving *deps to "=" instead of ">=" for preventing problems like this in the future :-/
Even so, a package's deps should be written such that mixing testing and stable packages doesn't break them.
(In reply to comment #9) > Even so, a package's deps should be written such that mixing testing and stable > packages doesn't break them. > the problem is that, even changing deps to allow its installation together (that would also require some extra work), they could also break in other ways since, for example, people could mix some gtk libs generated with current stable X libs with some old ones. You can also look to examples like qtlibs: current stable one depends soundlibs with arts support, its RDEPEND is also wrong since it's ">=" and current testing one doesn't provide any arts support. Then, the most reasonable option from my point of view is to force people to use the same version for their emul packages (when they rdepends between them of course), since it's the situation we test and support.
Changes comitted to 20081109 and 20091226 (the other ones will be cleaned sooner or later) Regards
