From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([69.77.167.62] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1JVGuB-0006Tt-NC for garchives@archives.gentoo.org; Sat, 01 Mar 2008 01:52:51 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id C2E05E0481; Sat, 1 Mar 2008 01:52:36 +0000 (UTC) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by pigeon.gentoo.org (Postfix) with ESMTP id 6825EE0481 for ; Sat, 1 Mar 2008 01:52:36 +0000 (UTC) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JVGtp-0000Af-Pk for gentoo-amd64@lists.gentoo.org; Sat, 01 Mar 2008 01:52:29 +0000 Received: from ip68-231-12-179.ph.ph.cox.net ([68.231.12.179]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 01 Mar 2008 01:52:29 +0000 Received: from 1i5t5.duncan by ip68-231-12-179.ph.ph.cox.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 01 Mar 2008 01:52:29 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-amd64@lists.gentoo.org From: Duncan <1i5t5.duncan@cox.net> Subject: [gentoo-amd64] Re: revdep-rebuild keep on detecting a broken link referred to libqt-mt.so.3 Date: Sat, 1 Mar 2008 01:52:21 +0000 (UTC) Message-ID: References: <47C6789C.2060508@manuelmarano.com> <47C836DD.50808@xaerolimit.net> <47C83FBF.3080905@xaerolimit.net> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-amd64@lists.gentoo.org Reply-to: gentoo-amd64@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: ip68-231-12-179.ph.ph.cox.net User-Agent: Pan/0.132 (Waxed in Black) Sender: news Content-Transfer-Encoding: quoted-printable X-Archives-Salt: b1772ef8-0990-4208-abe1-541092d4555c X-Archives-Hash: f39d180b73dc9826b0f817649c4d9669 Chris Brennan posted 47C83FBF.3080905@xaerolimit.net, excerpted below, on Fri, 29 Feb 2008 12:24:15 -0500: [Duncan wrote...] >> Hmm... so what about /usr/qt/3/lib/libqt-mt.so ? Here, it's a symlink >> pointing to libqt-mt.so.3, a symlink pointing to libqt-mt.so.3.3, agai= n >> a symlink, pointing at libqt-mt.so.3.3.8, which is the actual >> shared-object library file. >=20 > the point was the error msg from the emerge output about wrong format. The problem is, "wrong format" can mean symlink pointed at nothing, in so= me contexts. If the target file doesn't exist... It can also mean it's for some reason it's pointed at a text file, or a file of the wrong bitness, or a file-system corrupt file, or..., which is what the next part is about. >> If you have a valid set of symlinks, pick any one of them and see what >> readelf -h says about it. If the class entry (right under magic) is >> anything other than ELF64, then you have a corrupted library and >> probably need to remerge qt (be sure you remerge qt3 not 4, if you hav= e >> it merged as well). If it's ELF64 and appears to be readable, then yo= u >> have other deeper problems. >=20 > I have re-emerged qt-3 numerous times, here is the output of readelf >=20 > xaero@Leviathan ~ $ readelf -h /usr/qt/3/lib/libqt-mt.so.3.3.8 ELF > Header: > Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 > Class: ELF32 That's the problem right there. It's trying to link a 32-bit library into (presumably, since this is the amd64 list/group) a 64-bit ELF binary. That's just not going to work, period, and remerging the 64-bit qt isn't going to correct the problem either (unless it overwrites the file, which it obviously doesn't if you've tried it already). That's progress. Now, we need to find out if any packages you have merged, probably emul-linux-x86-* packages since that's where the 32-bit stuff comes from unless you are running a full 32-bit chroot, and I've no indication of that. equery belongs libqt-mt.so.3.3.8 I didn't use the path, since lib and lib64 are normally symlinked one way or the other on amd64, and if you searched by path, you'd need to search for both paths. Here, I get one (just one) entry, but I'm running no-multilib since I don't do binary-only and that's about the only reason one might have for 32-bit. [ Searching for file(s) libqt-mt.so.3.3.8 in *... ] x11-libs/qt-3.3.8-r4 (/usr/qt/3/lib64/libqt-mt.so.3.3.8) So it's the 64-bit qt package that owns it, here. What about there? Do two packages own it and do both point at the same file, possibly thru different directory/symlink paths? None? If none it's an orphaned file and you /should/ be able to remove it safely, but you may want to move it somewhere out of the library search path but keep it around for awhile just in case. If only the 64-bit package points to it, same thing, but remerge the 64-bit qt afterward, and I frankly don't know why remerging it with that file in place didn't fix the problem. If one and it's 32-bit, then you have a problem with the lib-linking search path. First, check for updates to the 32-bit emul-linux-* package and try that if there are any. Else there are ways to fix it but you'll need to get someone with more knowledge in the field to help, as I never had the problem on multilib myself and now am 64-bit only so haven't bothered with the details. If two, and both paths point to the same thing, it's something portage's config-protect FEATURE should have caught if you have it enabled. Again, check for updates on the 32-bit package and try them first, then seek further help, but in this case it's a bug that should either be in Gentoo's bugzilla already or that you can file if not. --=20 Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman --=20 gentoo-amd64@lists.gentoo.org mailing list