After a recent emerge -DuN world, messages for one of the packages stated that it was necessary to run revdep-rebuild after emerging the package, so I did. The revdep-rebuild ended up merging six packages, with one of them being gcc. Emerging all six packages took several hours, and I noticed that gcc by itself took a significant amount of time.
The final message stated that I could re-run revdep-rebuild to verify that all inconsistencies had been resolved, unfortunately, I did not add a -p to the command and to my surprise it spent the next couple of hours or so emerging gcc again. After that finished, I again ran revdep-rebuild although this time with a -p and below is the output: ______________________________________ 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... done. (/root/.revdep-rebuild.1_files) Collecting complete LD_LIBRARY_PATH... done. (/root/.revdep-rebuild.2_ldpath) Checking dynamic linking consistency... broken /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/libgcjawt.la (requires /usr/lib/lib-gnu-java-awt-peer-gtk.la) broken /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/libgij.la (requires /usr/lib/libgcj.la) done. (/root/.revdep-rebuild.3_rebuild) Assigning files to ebuilds... done. (/root/.revdep-rebuild.4_ebuilds) Evaluating package order... done. (/root/.revdep-rebuild.5_order) All prepared. Starting rebuild... emerge --oneshot -p =sys-devel/gcc-4.1.2 These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] sys-devel/gcc-4.1.2 Now you can remove -p (or --pretend) from arguments and re-run revdep-rebuild. ______________________________________ It wants to build gcc again. I don't want to have to build gcc every time I need to use revdep-rebuild. The final message from revdep-rebuild is: ____________________ Build finished correctly. Removing temporary files... You can re-run revdep-rebuild to verify that all libraries and binaries are fixed. If some inconsistency remains, it can be orphaned file, deep dependency, binary package or specially evaluated library. ____________________ How do I determine if this is a case of "orphaned file, deep dependency, binary package or specially evaluated library" and, if it is one of those, how do I determine which one, and then how do I fix this...? Thanks for listening, Bob Young San Jose, CA -- gentoo-user@lists.gentoo.org mailing list
