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 45F8D13838B for ; Sun, 21 Sep 2014 21:55:33 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id B27A2E089B; Sun, 21 Sep 2014 21:55:31 +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 143E6E089B for ; Sun, 21 Sep 2014 21:55:30 +0000 (UTC) Received: from [192.168.3.7] (cpe-74-77-145-97.buffalo.res.rr.com [74.77.145.97]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: blueness) by smtp.gentoo.org (Postfix) with ESMTPSA id 1BD8633FE13 for ; Sun, 21 Sep 2014 21:55:29 +0000 (UTC) Message-ID: <541F4951.4000409@gentoo.org> Date: Sun, 21 Sep 2014 17:55:29 -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> <5419DD6F.4000801@opensource.dyc.edu> <5419E3FF.9050408@gentoo.org> <5419E690.5010905@gentoo.org> <5419EB70.10209@gentoo.org> <5419ECD0.7000903@gentoo.org> In-Reply-To: <5419ECD0.7000903@gentoo.org> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 8bit X-Archives-Salt: 2b38cb5c-e12f-485c-b235-693e3e69da10 X-Archives-Hash: be6eb448d9b99bbfcc91252c301dd6c2 On 09/17/14 16:19, Anthony G. Basile wrote: > On 09/17/14 16:13, Markos Chandras wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA512 >> >> On 09/17/2014 08:52 PM, Anthony G. Basile wrote: >>> On 09/17/14 15:41, Markos Chandras wrote: 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? >>> >>>> Yes it would be more backwards compat, but it is not semetrical. >>>> The regular (ie glibc) profiles would become: >>>> [1] default/linux/mips/13.0/o32 <-change [2] >>>> default/linux/mips/13.0/n32 [3] default/linux/mips/13.0/n64 [4] >>>> default/linux/mips/13.0/multilib/o32 <-change [5] >>>> default/linux/mips/13.0/multilib/n32 [6] >>>> default/linux/mips/13.0/multilib/n64 [7] >>>> default/linux/mips/13.0/mipsel/o32 <- change [8] >>>> default/linux/mips/13.0/mipsel/n32 [9] >>>> default/linux/mips/13.0/mipsel/n64 [10] >>>> default/linux/mips/13.0/mipsel/multilib/o32 <-change [11] >>>> default/linux/mips/13.0/mipsel/multilib/n32 [12] >>>> default/linux/mips/13.0/mipsel/multilib/n64 >> I think that if you symlink the following >> >> default/linux/mips/13.0/eapi -> default/linux/mips/13.0/o32/eapi >> default/linux/mips/13.0/parent -> default/linux/mips/13.0/o32/parent >> >> existing default/linux/mips/13.0/ users will be unaffected. But I am >> not sure if we are allowed to use symlinks (same thing for mipsel) >> >> If we can't avoid it then we can send the usual email to the lists >> informing users for the change. I believe it's not hard for them to >> figure out what changed and how to select the proper profile for their >> mips32 boxes. > > Let me test first the new profiles. I will put them on the > hardened-dev::profile overlay. I know they're not hardened, but we do > testing of big changes to profiles there. Then you can review what > I've done. > > I'm not sure about the sym links either. > This isn't going to work. The problem is that the above structure doesn't distinguish between mips/o32 and mips64/o32 (and equivalent el versions). Now mips64/o32 is funny, but possible: it would be o32 (a 32-bit abi) on 64 bit arch/kernel, like ppc64-32ul. The structure is possible at the level of profile/arch, but it would mean a deep restructuring of default/linux/mips/13.0. I'm not sure we want to make such a deep change. The profiles we would present to the user would look like: [1] default/linux/mips/13.0/mips/o32 default/linux/mips/13.0/mips64/o32 <- distinguish the mips/o32 and mips64/o32 [2] default/linux/mips/13.0/mips64/n32 [3] default/linux/mips/13.0/mips64/n64 [4] default/linux/mips/13.0/multilib/o32 <- multilib is necessarily mips64 [5] default/linux/mips/13.0/multilib/n32 <- multilib is necessarily mips64 [6] default/linux/mips/13.0/multilib/n64 <- multilib is necessarily mips64 [7] default/linux/mips/13.0/mipsel/o32 default/linux/mips/13.0/mips64el/o32 <- distinguish the mipsel/o32 and mips64el/o32 [8] default/linux/mips/13.0/mips64el/n32 [9] default/linux/mips/13.0/mips64el/n64 [10] default/linux/mips/13.0/mipsel/multilib/o32 <- multilib is necessarily mips64el [11] default/linux/mips/13.0/mipsel/multilib/n32 <- multilib is necessarily mips64el [12] default/linux/mips/13.0/mipsel/multilib/n64 <- multilib is necessarily mips64el No need to touch the rest. [13] hardened/linux/musl/mips [14] hardened/linux/musl/mips/mipsel [15] default/linux/uclibc/mips [16] hardened/linux/uclibc/mips [17] default/linux/uclibc/mips/mipsel [18] hardened/linux/uclibc/mips/mipsel Maybe we just don't want to support mips64/o32? I'm starting to lean towards Ian's simple but asymmetric solution of turning off o32 in the inheriting profiles. -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail : blueness@gentoo.org GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA GnuPG ID : F52D4BBA