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 476AE13838B for ; Wed, 17 Sep 2014 20:16:44 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id D1138E09B4; Wed, 17 Sep 2014 20:16:43 +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 699D6E09B4 for ; Wed, 17 Sep 2014 20:16:43 +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 813A434000E for ; Wed, 17 Sep 2014 20:16:42 +0000 (UTC) Message-ID: <5419ECD0.7000903@gentoo.org> Date: Wed, 17 Sep 2014 16:19:28 -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> In-Reply-To: <5419EB70.10209@gentoo.org> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 8bit X-Archives-Salt: bd537ebd-d095-4a10-bcde-e1ea14cd4ecd X-Archives-Hash: f249e8209abc26499c3e4992303dcc50 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. > - -- > Regards, > Markos Chandras > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > > iQF8BAEBCgBmBQJUGetvXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w > ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGRDlGMzA4MUI2MzBDODQ4RDBGOEYxMjQx > RjEwRUQ0QjgxREVCRjE5AAoJEB8Q7UuB3r8ZA2UH/j9O3h3cuvoFEJnRFvGOoLHF > c0tQykVpAjcJm4G6fEDLS1+soRl+U8PENxM3cnqEeLWsz9qRTyB9QJCF6s2cg6tr > /7eUWn3OnFD5jSW9A16BiX0vpKGCdJFz30HDN6zFJpuOj2jhKOeZplNgDICQtJr2 > yBsv7q9rN99MQc/hEQK8tvffIibrVNlNIyKb6YoRuzuPycu5v6thiTFwPSyWh8Q/ > qqdokI024Qg4DqGhwSd1puq2iISaT4xH2Fn6ZgR0pyHFwy0bQx9IRNe0cjZfP2yJ > biCZqcG0S5VOFv161FbnA3EyutuFIzRJs60EqnyjkezlDvXJqNOmTdePYdS5/T4= > =TPCw > -----END PGP SIGNATURE----- > -- 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