x11-libs/libX11-1.3.2 missing dependencies on x11-libs/libXext and x11-libs/libXxf86vm. xorg-server wants them installed, but libX11 is first in the compile order, and seems to not link without. x11-libs/libXxf86vm pulls in x11-libs/libX11, which can't build without x11-libs/libXxf86vm, so not exactly sure how to proceed. I'm confused. make[2]: Entering directory `/var/tmp/portage/x11-libs/libX11-1.3.2/work/libX11-1.3.2/specs/libX11' GEN libX11.txt GEN libX11.html GEN libX11.ps GEN libX11.pdf gs: error while loading shared libraries: libXxf86vm.so.1: cannot open shared object file: No such file or directory make[2]: *** [libX11.pdf] Error 127 make[2]: *** Waiting for unfinished jobs.... rm libX11.ps make[2]: Leaving directory `/var/tmp/portage/x11-libs/libX11-1.3.2/work/libX11-1.3.2/specs/libX11' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/var/tmp/portage/x11-libs/libX11-1.3.2/work/libX11-1.3.2/specs' make: *** [all-recursive] Error 1 * * ERROR: x11-libs/libX11-1.3.2 failed. * Call stack: * ebuild.sh, line 49: Called src_compile * environment, line 3246: Called x-modular_src_make * environment, line 4105: Called die * The specific snippet of code: * emake || die "emake failed" * The die message: * emake failed
x11-libs/libXxf86vm builds with "emerge --nodeps", (had libX11-1.2.2 installed). Hope that wasn't a bad idea...
Probably you need to unmerge ghostscript for the moment, but that output suggests somebody just got burned by depclean ?
(In reply to comment #2) > Probably you need to unmerge ghostscript for the moment, > but that output suggests somebody just got burned by depclean ? Some things were uninstalled due to being blockers, when trying to upgrade mesa (which meant having to upgrade xorg, too). I guess x11-libs/libXxf86vm-1.0.2 was one of them. No depclean involved. I reemerged x11-libs/libXxf86vm, in case anything broke in it when installing it with --nodeps.
libX11 depends on ghostscript to compile the manual, and ghostscript's gs is linked against X apparently, so no, libX11 should not depend on a library that ghostscript can't find. Did you run revdep-rebuild yet?
(In reply to comment #4) > libX11 depends on ghostscript to compile the manual, and ghostscript's gs is > linked against X apparently, so no, libX11 should not depend on a library that > ghostscript can't find. Did you run revdep-rebuild yet? I hadn't run revdep-rebuild. I just ran it, it found some things, but nothing in any way related (just libquicktime, things like that). "Forcing" it to build x11-libs/libXxf86vm first seems to have fixed the problem for me, and I didn't rebuild ghostscript. I guess the problem was some bad combination of blockers and dependencies (and probably the "doc" use flag), maybe I just upgraded at the wrong time. I don't remember now, whether it automatically uninstalled the blocked packages, or if I did it manually.
OK, so the problem went away of its own accord. :)
