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 27C6E13838B for ; Wed, 17 Sep 2014 19:41:58 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id C8A92E0912; Wed, 17 Sep 2014 19:41:56 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 6331DE0912 for ; Wed, 17 Sep 2014 19:41:56 +0000 (UTC) Received: from [192.168.1.2] (unknown [2.223.209.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: hwoarang) by smtp.gentoo.org (Postfix) with ESMTPSA id A47613401BF for ; Wed, 17 Sep 2014 19:41:54 +0000 (UTC) Message-ID: <5419E3FF.9050408@gentoo.org> Date: Wed, 17 Sep 2014 20:41:51 +0100 From: Markos Chandras User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.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> <5419DD6F.4000801@opensource.dyc.edu> In-Reply-To: <5419DD6F.4000801@opensource.dyc.edu> Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 8bit X-Archives-Salt: 1ed8a0b7-e687-4322-9d54-360984ef9615 X-Archives-Hash: 10a14d0618bb44dfe1867e454aa4de43 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 09/17/2014 08:13 PM, Anthony G. Basile wrote: > On 09/17/14 13:50, Markos Chandras wrote: 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. > Well i need to see the structure for your second approach to understand what you have in mind. Perhaps the first option is the safest and ensure some backwards compatibility with existing mips32 users? - -- Regards, Markos Chandras -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJUGeP/XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGRDlGMzA4MUI2MzBDODQ4RDBGOEYxMjQx RjEwRUQ0QjgxREVCRjE5AAoJEB8Q7UuB3r8Z5msH/1YBYb9trZYGrkXkR0FIcx9Y ltJ8PL7jGG1B4NO0PJJpwehMSsxFbkpq3VT9ahrVq4+K58/3XRDmoWGEsWpBIo3o KHCmCOoC2KPmGFEXofKsD7iAlb83X5/KsHVhHioUy/5D7JMf4PrPLPjkMtRFU0oR h9+hah+3tSMO5QUh4blXnYJ4LeE298GjPJMwPtMlhx4uRUyXeRhUfuINzdf9uMBV FFHfJKOfsr9aizUpJxza/Wph+IA+NVGTCekZzWQ6gSZW+MxiF3mAeLFj6I6g+0lI Ga8+Z1Bs/JM7P4csLJ2Sp+ccgaIGXg6xU/BtlpKyJl745mpBAt58w17762+ivjs= =PqPy -----END PGP SIGNATURE-----