<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Duncan ha scritto:
<blockquote cite="mid:pan.2008.02.28.19.02.47@..." type="cite">
<pre wrap="">manuel <a class="moz-txt-link-rfc2396E" href="mailto:kaos@..."><kaos@...></a> posted <a class="moz-txt-link-abbreviated" href="mailto:47C6789C.2060508@...">47C6789C.2060508@...</a>,
excerpted below, on Thu, 28 Feb 2008 10:02:20 +0100:
</pre>
<blockquote type="cite">
<pre wrap="">Hi All,
I've ran revdep-rebuild a couple of times this week and each time i
run it it finds a broken link referred to libqt-mt.so.3 and each
time It emerges
app-emulation/emul-linux-x86-soundlibs-2007112 to correct the problem!
but the broken link is still there!?? I can't fix it! any ideas?
</pre>
</blockquote>
<pre wrap=""><!---->
Realize that the emul-linux-x86 stuff is binary. That is, it's prebuilt;
the ebuild simply installs it, because compiling it as 32-bit on a 64-bit
multilib system is possible but rather a hassle to setup correctly, so
the 32-bit binary emul-linux stuff is provided as a convenience for those
who don't wish to go thru that hassle.
As a binary, you can remerge it all day every day and it's not going to
change the binaries inside. Thus, you can't correct linking therein. A
new binary package would be required for that.
However, such binaries aren't critical for a 64-bit system anyway. All
they do is support 32-bit binary-only games and the like, if you choose
to install and run them. Thus, the broken linkage isn't a big deal
unless it's stopping you from running that game or whatever, and even
then, it's not interfering with the normal functioning of the computer in
general.
To fix it, you'd either need to wait for an updated build, merge whatever
additional emul-linux package it's linking against (but the remerge
should have cured the problem if it were that, as it would have pulled in
the other package), or do the whole 32-bit chroot thing and use it rather
than the emul-linux stuff.
If all you wish to do is get revdep-rebuild to shutup, that is, set it to
ignore that package since remerging it isn't going to help, that's
possible too. See the revdep-rebuild manpage for the details, but
basically, you put an entry in either make.conf itself, or in a file in
/etc/revdep-rebuild, telling revdep-rebuild what to ignore. (This
feature has been in the ~arch revdep-rebuild version for some time. I
assume it's in arch-stable versions by now. If not and you're running
stable, consider running ~arch gentoolkit, using the appropriate
package.keywords entry.)
</pre>
</blockquote>
Great!!<br>
thanks for the help<br>
<br>
Manuel<br>
</body>
</html>
|
