| 1 |
Brian Litzinger posted <20051101173928.GA13381@localhost>, excerpted |
| 2 |
below, on Tue, 01 Nov 2005 09:39:29 -0800: |
| 3 |
|
| 4 |
> Been ~amd64 since the day I got this laptop. |
| 5 |
> |
| 6 |
> The last time I hit the problem was on |
| 7 |
> |
| 8 |
> lrwxrwxrwx 1 root root 15 Oct 21 14:43 /usr/lib/libungif.so.4 -> |
| 9 |
> libgif.so.4.1.3 |
| 10 |
> |
| 11 |
> when I finally got tired and created the link. |
| 12 |
> |
| 13 |
> Thus on Oct 21st at 13:43 (PST) you could still experience the |
| 14 |
> problem as a ~amd64 type. |
| 15 |
> |
| 16 |
> I got slapped in the face as a small child for filing a duplicate |
| 17 |
> bug. Thus I am, as an adult, unable to file bugs. :( |
| 18 |
|
| 19 |
Did you do what I and others have suggested, a revdep-rebuild? Note that |
| 20 |
existing packages on your system may still be linked against the old |
| 21 |
library. Once it's in their binaries... |
| 22 |
|
| 23 |
revdep-rebuild (as with anything portage related, run it with the -p the |
| 24 |
first time thru to see what it's going to do) is designed to scan your |
| 25 |
existing binaries to see what they need, and your existing library path |
| 26 |
(that ld uses to find the libs it needs) to see what's provided. Then it |
| 27 |
makes a list of all the binaries (both executables, and libs that load |
| 28 |
other libs) that have unfilled dependencies using the existing libraries, |
| 29 |
traces down the packages they belong to, and remerges them (or with -p, |
| 30 |
displays what it would merge), the intent being to recompile and relink |
| 31 |
anything that's missing dependencies, either linking against new or |
| 32 |
alternate versions of same, or pulling in the required dependencies to |
| 33 |
merge as well. |
| 34 |
|
| 35 |
Of course, this only works once that library has gone missing. If you run |
| 36 |
revdep-rebuild with the library (or a symlink pointing to an alternate) |
| 37 |
still there, it'll think everything is fine and not list the package |
| 38 |
owning the library in question for remerge. |
| 39 |
|
| 40 |
Decently updated packages that formerly linked against libungif should now |
| 41 |
link against libgif without difficulty. However, with existing package on |
| 42 |
the system linked against libungif, it's only to be expected that said |
| 43 |
binaries would have issues. The easiest way to fix them is to run |
| 44 |
revdep-rebuild. In fact, revdep-rebuild, along with emerge --newuse |
| 45 |
--update --deep world, should be a regular part of the routine to keep a |
| 46 |
well maintained and upto date system. |
| 47 |
|
| 48 |
(Another part of the same routine should be emerge depclean, but be sure |
| 49 |
the revdep-rebuild and emerge --newuse are completed first, and check the |
| 50 |
output of a --pretend depclean for stuff you know you want to keep around, |
| 51 |
before letting it do its thing. Then run revdep-rebuild again afterward, |
| 52 |
just to be sure.) |
| 53 |
|
| 54 |
These apply to some degree to everyone, but a bit less to slower moving |
| 55 |
stable, than to faster moving ~arch. Since ~arch may merge three versions |
| 56 |
for every version that goes stable, including beta and rc versions on |
| 57 |
occasion, cruft tends to buildup rather faster than it will on a stable |
| 58 |
system. |
| 59 |
|
| 60 |
-- |
| 61 |
Duncan - List replies preferred. No HTML msgs. |
| 62 |
"Every nonfree program has a lord, a master -- |
| 63 |
and if you use the program, he is your master." Richard Stallman in |
| 64 |
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html |
| 65 |
|
| 66 |
|
| 67 |
-- |
| 68 |
gentoo-amd64@g.o mailing list |
Archives