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 1JVJ4w-0007Uy-ME for garchives@archives.gentoo.org; Sat, 01 Mar 2008 04:12:06 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 254E4E06C5; Sat, 1 Mar 2008 04:12:05 +0000 (UTC) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.182]) by pigeon.gentoo.org (Postfix) with ESMTP id D61F8E06C5 for ; Sat, 1 Mar 2008 04:12:04 +0000 (UTC) Received: by wa-out-1112.google.com with SMTP id k34so5805543wah.10 for ; Fri, 29 Feb 2008 20:12:04 -0800 (PST) Received: by 10.114.210.2 with SMTP id i2mr909296wag.36.1204344724248; Fri, 29 Feb 2008 20:12:04 -0800 (PST) Received: from ?192.168.1.2? ( [68.44.91.8]) by mx.google.com with ESMTPS id k26sm20493547waf.8.2008.02.29.20.12.02 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 29 Feb 2008 20:12:03 -0800 (PST) Message-ID: <47C8D787.5060100@xaerolimit.net> Date: Fri, 29 Feb 2008 23:11:51 -0500 From: Chris Brennan User-Agent: Thunderbird 2.0.0.9 (X11/20080209) 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 To: gentoo-amd64@lists.gentoo.org Subject: Re: [gentoo-amd64] Re: revdep-rebuild keep on detecting a broken link referred to libqt-mt.so.3 References: <47C6789C.2060508@manuelmarano.com> <47C836DD.50808@xaerolimit.net> <47C83FBF.3080905@xaerolimit.net> In-Reply-To: X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Archives-Salt: 3c230d37-a698-47ae-a2db-ead60b24912d X-Archives-Hash: a93cc14e2327254d7a44fcbe1fb63476 Duncan wrote: > 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, again >>> a symlink, pointing at libqt-mt.so.3.3.8, which is the actual >>> shared-object library file. >> 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 some > 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 have >>> it merged as well). If it's ELF64 and appears to be readable, then you >>> have other deeper problems. >> I have re-emerged qt-3 numerous times, here is the output of readelf >> >> 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. > app-emulation/emul-linux-x86-qtlibs seems to have been the culprit, I don't need it for anything that I can tell. It's been removed for now and I have moved on to building the app I intended to build when all this started (which was The Gimp). As of the writing of this, it is building. -- gentoo-amd64@lists.gentoo.org mailing list