From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 0205C13838B for ; Wed, 17 Sep 2014 19:11:08 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id A8648E01B5; Wed, 17 Sep 2014 19:11:05 +0000 (UTC) Received: from virtual.dyc.edu (mail.virtual.dyc.edu [67.222.116.22]) by pigeon.gentoo.org (Postfix) with ESMTP id 44BEEE01B5 for ; Wed, 17 Sep 2014 19:11:05 +0000 (UTC) Received: from [192.168.3.7] (cpe-74-77-145-97.buffalo.res.rr.com [74.77.145.97]) by virtual.dyc.edu (Postfix) with ESMTPSA id 81E217E01AD for ; Wed, 17 Sep 2014 15:11:04 -0400 (EDT) Message-ID: <5419DD6F.4000801@opensource.dyc.edu> Date: Wed, 17 Sep 2014 15:13:51 -0400 From: "Anthony G. Basile" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.8.0 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-mips@lists.gentoo.org Reply-to: gentoo-mips@lists.gentoo.org MIME-Version: 1.0 To: gentoo-mips@lists.gentoo.org Subject: Re: [gentoo-mips] multilib problems on mips64 profiles References: <541412C5.4090809@gentoo.org> <20140917103121.6e822b45@pomiot.lan> <54198ECB.7010803@gentoo.org> <5419C9FD.6060106@gentoo.org> In-Reply-To: <5419C9FD.6060106@gentoo.org> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 8bit X-Archives-Salt: 0ed298a4-b26e-45bb-b537-53033d0d1924 X-Archives-Hash: 465f8b66a4f0bfbe51fe78e2ae1035cf On 09/17/14 13:50, Markos Chandras wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > On 09/17/2014 02:38 PM, Ian Stakenvicius wrote: >> On 17/09/14 04:31 AM, Michał Górny wrote: >>> Dnia 2014-09-13, o godz. 10:47:49 Markos Chandras >>> napisał(a): >> >>>> Here is some weirdness with eg mips64/n32 multilib profile >>>> when trying a world update >>>> >>>> [ebuild U ] sys-devel/libtool-2.4.2-r1:2 [2.4.2:2] >>>> USE="-static-libs {-test} -vanilla" ABI_MIPS="(n32%*) o32%* >>>> -n64%" 0 kB >>>> >>>> As you can see n32 and o32 are enabled but n64 is not. >>>> Obviously this is not full mips64 multilib. This is probably >>>> due the portage profile stacking/inheritance problems on >>>> mips64, where the mips64/multilib profiles inherit the default >>>> o32 one. Michal (multilib CC'd) can provide more information on >>>> what exactly goes wrong since he understands the problem better >>>> than me. Michal also said that on amd64, the multilib profiles >>>> defaults to 64-bit only. I believe this contradicts with what >>>> someone expects from MIPS64 where all three ABIs need to be >>>> present *by default* unless you override the ABI_MIPS variable >>>> in make.conf. Correct? >> >>> Well, long story short we inherit from 'top-level' profile that >>> has some o32 settings inside. I believe that it could be saner >>> to move those from arch/mips/mips64 -> arch/mips/mips64/o32 (like >>> we have /n32 and /n64 there), so that instead of having to unset >>> them, we'd just have them set for the relevant real profiles. >> >>> However, I'm not sure if this doesn't come with some pitfalls. >> >> >> Blueness and I talked about this (proper n32 / n64 / o32 defaults >> and forces/masks) in #gentoo-dev two or three weeks ago; I thought >> we worked out the correct modifications to profiles to get it right >> and he had already pushed the fixes... ?? > > I can't see anything. Did you actually push them? What was decided as > the plan for action? I did not have time to get to them. I was going to play with two different approaches. One is simply turning off o32 at multilib/../n32 level, the other was to restructure the profiles entirely and put o32, n32 and 64 on par, not inherit from a hire level "default" profile. I'm leaning towards that approach, but I'm worried it might play havoc on our users. > >> >> Is it just a matter of documenting the full map of exactly what >> multilib profile should be forced-on and default-on in each, and >> then either adjusting profiles if they don't match up OR allowing >> users to select the correct profile for what they want? >> >> For example, i'm not understanding why n64 -should- be enabled by >> default on the mips64/n32 profile?? If you wanted more than >> {n,o}32 shouldn't you be choosing the base mips64 profile? >> >> > Perhaps it should not but neither should o32 > > - -- > Regards, > Markos Chandras > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > > iQF8BAEBCgBmBQJUGcn9XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w > ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGRDlGMzA4MUI2MzBDODQ4RDBGOEYxMjQx > RjEwRUQ0QjgxREVCRjE5AAoJEB8Q7UuB3r8ZjSIH/3g0y2CTrZrJtmo7n9XvUIBK > F35WepF3zkkKE6BFxNF1qbLE7OrIUbhERZzn3bDdEz/9vBlE/oMfrV+M2tbdMX77 > rohS5jvAQN5F2TYhdtJBWrDV1PRidfTIx+qAL1IFIw+xNA96Wzyy+TveqRYb6BG5 > jqIHvyNdFu8yZKGp5OEbJgz9Jk/d4bB4cDPkIKbZODWl2aD6iuVO6hvSveB9WQrd > Rmair7kUi27Drrr8aNd0pt9tF0PFoFM1+Tt1axLXWDHkx3gLsqCEg7fXSKHsoUGO > kJH8WcWhJiYhK4nN+NJuaBm35UKFpZMY1ac5iA8UoR92QN00NqAeiMa+vMt9u7s= > =wYWx > -----END PGP SIGNATURE----- > -- Anthony G. Basile, Ph. D. Chair of Information Technology D'Youville College Buffalo, NY 14201 (716) 829-8197