From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.43) id 1E1iFi-0004nh-QY for garchives@archives.gentoo.org; Sun, 07 Aug 2005 10:19:35 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.4/8.13.4) with SMTP id j77AHfDV008598; Sun, 7 Aug 2005 10:17:41 GMT Received: from buggy.blubb.ch (range21-65.shlink.ch [217.148.7.65]) by robin.gentoo.org (8.13.4/8.13.4) with ESMTP id j77AHftU011508 for ; Sun, 7 Aug 2005 10:17:41 GMT Received: from aqua ([192.168.10.5]) by buggy.blubb.ch with esmtp (Exim 4.50) id 1E1iDq-0006dT-HN for gentoo-amd64@lists.gentoo.org; Sun, 07 Aug 2005 12:17:38 +0200 Message-ID: <42F5E011.8020907@gentoo.org> Date: Sun, 07 Aug 2005 12:18:57 +0200 From: Simon Stelling User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050716) X-Accept-Language: en-us, en Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-amd64@gentoo.org Reply-to: gentoo-amd64@lists.gentoo.org MIME-Version: 1.0 To: gentoo-amd64@lists.gentoo.org Subject: Re: [gentoo-amd64] file type not allowed in /usr/lib References: <42F53B6D.1080908@burnieanglican.org.au> In-Reply-To: <42F53B6D.1080908@burnieanglican.org.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Archives-Salt: 2fe27117-bc62-41dc-8bf0-358c105029fa X-Archives-Hash: 23ef4f350cac327dde59d18660b03f45 Hi, Will Briggs wrote: > !!! ERROR: media-gfx/skencil-0.6.16 failed. > !!! Function dyn_install, Line 1114, Exitcode 0 > !!! File > /var/tmp/portage/skencil-0.6.16/image///usr/lib/skencil-0.6.16/Lib/paxtkinter.so > matches a file type that is not allowed in /usr/lib > !!! If you need support, post the topmost build error, NOT this status > message. This means that there are 64bit shared objects going to /usr/lib instead of /usr/lib64, which is wrong, but currently not really a bug, since /usr/lib is a link to /usr/lib64. > So if anyone can help with a fix, please let me know. Just remove 'multilib-strict' from your FEATURES. > The _question_ relates to the fact that I've seen this sort of error a > number of times, but by the time I come across it it's been bugged and > fixed and the next emerge sync fixes it. Can someone let me know what > the issue is here - (mainly so I can get a handle on hacking my own > fixes when bug reports go unanswered) Why can't a .so file be placed in > /usr/lib? It can, but it shouldn't. We want 64bit .sos to go to (/usr)/lib64 and 32bit to (/usr)/lib32, because *taking a deep breath*: Generally, we want to provide a fully multilib-capable system. That means that you will be able to compile every application for 32bit or 64bit, depending on your mood ;). 32bit applications require 32bit libraries, otherwise they can't be linked against each other, same (obviously) for 64bit apps/libs. Now imagine you want appfoo (32bit) and appbar (64bit), both depending on libfoobar. So you need libfoobar twice -- once 64bit and once 32bit. Now, if libfoobar would get installed to /usr/lib instead /usr/lib32 and /usr/lib64, it'd obviously overwrite itself. Depending on what you install first, appfoo or appbar will break, as they both require installing libfoobar. Also, if you would emerge -C appfoo && emerge depclean, appbar wouldn't work anymore, because they both provide exactly the same files. The simple solution to this is making two directories and making sure that no 64bit shared object goes anywhere else than to (/usr)/lib64, and vice versa. Regards, -- Simon Stelling Gentoo/AMD64 Operational Co-Lead blubb@gentoo.org -- gentoo-amd64@gentoo.org mailing list