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 1JVOfd-00068n-SL for garchives@archives.gentoo.org; Sat, 01 Mar 2008 10:10:22 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 2E00FE059E; Sat, 1 Mar 2008 10:10:20 +0000 (UTC) Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.187]) by pigeon.gentoo.org (Postfix) with ESMTP id B5035E059E for ; Sat, 1 Mar 2008 10:10:19 +0000 (UTC) Received: by mu-out-0910.google.com with SMTP id i10so7573672mue.5 for ; Sat, 01 Mar 2008 02:10:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; bh=d0hcGAlPF9IOvEAn2+I/LaF5tGXkMm5s3xYSiYk0eG8=; b=GiCwlEjE1C2BmTHX2v2KevVPBjwL1ouR6/e70nGqs2G/FTcO1semleQgpuO67K15xVUuKAlbmY6KuXiAPNkh8ekq5HLN8k/BRMLEuvze+ePqPQYoH8Yap282VA/yYSSmuQruCcrE16GbOHubaFamP+LIRhzpOCE1VFutbWlnrho= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=O1qExU9yR2215UyWiQE1fCPkeJcHRUHnVp+cBeyVCQVhOLFG6oU266bsm5HJMwdKuFEALHnWHditTYEbgZumMJcLzYyF9XjpJRWoE3YHuksGbbv+IIG1vYpuQe7GHb1WlP/Ke4437v0kQ+ugWvdUSOaewK6Ge+UqDVbwBZKBRQk= Received: by 10.82.124.10 with SMTP id w10mr9674772buc.18.1204366218654; Sat, 01 Mar 2008 02:10:18 -0800 (PST) Received: by 10.82.141.15 with HTTP; Sat, 1 Mar 2008 02:10:18 -0800 (PST) Message-ID: Date: Sat, 1 Mar 2008 10:10:18 +0000 From: Beso 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 In-Reply-To: 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: multipart/alternative; boundary="----=_Part_1278_8132669.1204366218644" References: <47C6789C.2060508@manuelmarano.com> <47C836DD.50808@xaerolimit.net> <47C83FBF.3080905@xaerolimit.net> <47C8D787.5060100@xaerolimit.net> X-Archives-Salt: 3404065b-c91e-4ec4-810e-1c58757525e7 X-Archives-Hash: 6fdca6f21eb3759ba2b3730737212773 ------=_Part_1278_8132669.1204366218644 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline 2008/3/1, Duncan <1i5t5.duncan@cox.net>: > > Chris Brennan posted > > 47C8D787.5060100@xaerolimit.net, excerpted below, on Fri, 29 Feb 2008 > 23:11:51 -0500: > > > > 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. > > > Cool! =8^) > > Why it'd be putting a 32-bit lib in the standard lib dir is beyond me. > It's certainly a bug. It should be in a 32-bit compatibility dir (IDR > what it was for sure because as I said I don't do multilib now), with 64- > bit libs in lib64, which is usually symlinked one way or the other to lib > on a Gentoo system. The only stuff that should go in lib itself (as > opposed to lib64, even tho the two are linked, the package manager should > still say lib64 for 64-bit) is bitness independent stuff. For example, > bash/perl/python scripts are allowed to install to straight lib. > > So hopefully you don't end up needing that emul package for anything and > don't have to worry about it any more. try to control if /usr/lib symlink goes on /usr/lib64 or on /usr/lib32. it should never go to the 32bit lib on a 64bit machine. the same goes for the /lib symlink. also you might control what files has the emul-linux-x86-qtlibs via "qlist emul-linux-x86-qtlibs" and see if it has merged something in the 64bit lib (which shouldn't happen). also you might control the same thing with the the 64bit qt and see if there are some overlaps. -- dott. ing. beso ------=_Part_1278_8132669.1204366218644 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
2008/3/1, Duncan <1i5t5.duncan@cox.net>:
Chris Brennan <xaero@xaerolimit.net> posted

47C8D787.5060100@xaerolimit.net, excerpted below, on  Fri, 29 Feb 2008
23:11:51 -0500:


> 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.


Cool! =8^)

Why it'd be putting a 32-bit lib in the standard lib dir is beyond me.
It's certainly a bug.  It should be in a 32-bit compatibility dir (IDR
what it was for sure because as I said I don't do multilib now), with 64-
bit libs in lib64, which is usually symlinked one way or the other to lib
on a Gentoo system.  The only stuff that should go in lib itself (as
opposed to lib64, even tho the two are linked, the package manager should
still say lib64 for 64-bit) is bitness independent stuff.  For example,
bash/perl/python scripts are allowed to install to straight lib.

So hopefully you don't end up needing that emul package for anything and
don't have to worry about it any more.

try to control if /usr/lib symlink goes on /usr/lib64 or on /usr/lib32. it should never go to the 32bit lib on a 64bit machine. the same goes for the /lib symlink.
also you might control what files has the emul-linux-x86-qtlibs via "qlist emul-linux-x86-qtlibs" and see if it has merged something in the 64bit lib (which shouldn't happen). also you might control the same thing with the the 64bit qt and see if there are some overlaps.


--
dott. ing. beso ------=_Part_1278_8132669.1204366218644-- -- gentoo-amd64@lists.gentoo.org mailing list