[gentoo-user] revdep-rebuild command doesn't fix broken libs it finds
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
Re: [gentoo-user] revdep-rebuild command doesn't fix broken libs it finds
Bob Young wrote: 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: SNIP 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 This may help: http://bugs.gentoo.org/show_bug.cgi?id=125728 I'm not sure what changed but mine does not do this any more. I'm using app-portage/gentoolkit-0.2.3-r1 at the moment. Dale :-) :-) -- gentoo-user@lists.gentoo.org mailing list
Re: [gentoo-user] revdep-rebuild command doesn't fix broken libs it finds
Bob Young skrev: 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...? There are 2 commands: % qfile /path/to/file % equery b /path/to/file qfile is in app-portage/portage-utils and equery is in app-portage/gentoolkit. They both show which package a file belongs to. If the file does not belong to a package it is orphaned. Then it is up to you whether to keep or remove it. If it belongs to a package, check if it is binary. -- gentoo-user@lists.gentoo.org mailing list
RE: [gentoo-user] revdep-rebuild command doesn't fix broken libs it finds
-Original Message- From: Dale [mailto:[EMAIL PROTECTED] Sent: Sunday, March 02, 2008 12:18 AM To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] revdep-rebuild command doesn't fix broken libs it finds Bob Young wrote: 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 This may help: http://bugs.gentoo.org/show_bug.cgi?id=125728 I'm not sure what changed but mine does not do this any more. I'm using app-portage/gentoolkit-0.2.3-r1 at the moment. Dale :-) :-) Thanks Dale, After a little thought and some investigation I'd already come up with the symlink solution on my own. However I do find it a little disturbing that this is exactly the same, as a bug that has a creation date of: 2006-03-10, nearly two years ago. I also know that I didn't have this problem until a recent new stable version of gcc was merged. That means somebody is re-introducing bugs that have already been fixed. Making such easily avoidable mistakes does not bode well... Thanks Again, Bob Young San Jose, CA. -- gentoo-user@lists.gentoo.org mailing list
Re: [gentoo-user] revdep-rebuild command doesn't fix broken libs it finds
Bob Young wrote: -Original Message- From: Dale [mailto:[EMAIL PROTECTED] Sent: Sunday, March 02, 2008 12:18 AM To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] revdep-rebuild command doesn't fix broken libs it finds Bob Young wrote: 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 This may help: http://bugs.gentoo.org/show_bug.cgi?id=125728 I'm not sure what changed but mine does not do this any more. I'm using app-portage/gentoolkit-0.2.3-r1 at the moment. Dale :-) :-) Thanks Dale, After a little thought and some investigation I'd already come up with the symlink solution on my own. However I do find it a little disturbing that this is exactly the same, as a bug that has a creation date of: 2006-03-10, nearly two years ago. I also know that I didn't have this problem until a recent new stable version of gcc was merged. That means somebody is re-introducing bugs that have already been fixed. Making such easily avoidable mistakes does not bode well... Thanks Again, Bob Young San Jose, CA. It has been around for a while but I don't think it actually breaks anything. I have never had a problem with my system and it did that for ages. My workaround has always been to just oneshot everything but gcc and then rerun revdep-rebuild -i -p again to make sure the other problems were fixed. Of course, it would be good if it worked to begin with. Then again, I would rather a bug that breaks something be fixed first too. o_O I have gcc-4.1.2 installed here and I do not get that error. It is masked but no problems for me so far. Could it be that specific version of gcc you have maybe? Maybe someone else can chime in on what version they have and if they get that error or not. Glad to have helped. Dale :-) :-) :-) -- gentoo-user@lists.gentoo.org mailing list
