| 1 |
On 09/17/14 16:19, Anthony G. Basile wrote: |
| 2 |
> On 09/17/14 16:13, Markos Chandras wrote: |
| 3 |
>> -----BEGIN PGP SIGNED MESSAGE----- |
| 4 |
>> Hash: SHA512 |
| 5 |
>> |
| 6 |
>> On 09/17/2014 08:52 PM, Anthony G. Basile wrote: |
| 7 |
>>> On 09/17/14 15:41, Markos Chandras wrote: On 09/17/2014 08:13 PM, |
| 8 |
>>> Anthony G. Basile wrote: |
| 9 |
>>>>>> On 09/17/14 13:50, Markos Chandras wrote: On 09/17/2014 02:38 |
| 10 |
>>>>>> PM, Ian Stakenvicius wrote: |
| 11 |
>>>>>>>>> On 17/09/14 04:31 AM, Micha³ Górny wrote: |
| 12 |
>>>>>>>>>> Dnia 2014-09-13, o godz. 10:47:49 Markos Chandras |
| 13 |
>>>>>>>>>> <hwoarang@g.o> napisa³(a): |
| 14 |
>>>>>>>>>>> Here is some weirdness with eg mips64/n32 multilib |
| 15 |
>>>>>>>>>>> profile when trying a world update |
| 16 |
>>>>>>>>>>> |
| 17 |
>>>>>>>>>>> [ebuild U ] sys-devel/libtool-2.4.2-r1:2 |
| 18 |
>>>>>>>>>>> [2.4.2:2] USE="-static-libs {-test} -vanilla" |
| 19 |
>>>>>>>>>>> ABI_MIPS="(n32%*) o32%* -n64%" 0 kB |
| 20 |
>>>>>>>>>>> |
| 21 |
>>>>>>>>>>> As you can see n32 and o32 are enabled but n64 is |
| 22 |
>>>>>>>>>>> not. Obviously this is not full mips64 multilib. |
| 23 |
>>>>>>>>>>> This is probably due the portage profile |
| 24 |
>>>>>>>>>>> stacking/inheritance problems on mips64, where the |
| 25 |
>>>>>>>>>>> mips64/multilib profiles inherit the default o32 |
| 26 |
>>>>>>>>>>> one. Michal (multilib CC'd) can provide more |
| 27 |
>>>>>>>>>>> information on what exactly goes wrong since he |
| 28 |
>>>>>>>>>>> understands the problem better than me. Michal |
| 29 |
>>>>>>>>>>> also said that on amd64, the multilib profiles |
| 30 |
>>>>>>>>>>> defaults to 64-bit only. I believe this contradicts |
| 31 |
>>>>>>>>>>> with what someone expects from MIPS64 where all |
| 32 |
>>>>>>>>>>> three ABIs need to be present *by default* unless |
| 33 |
>>>>>>>>>>> you override the ABI_MIPS variable in make.conf. |
| 34 |
>>>>>>>>>>> Correct? |
| 35 |
>>>>>>>>>> Well, long story short we inherit from 'top-level' |
| 36 |
>>>>>>>>>> profile that has some o32 settings inside. I believe |
| 37 |
>>>>>>>>>> that it could be saner to move those from |
| 38 |
>>>>>>>>>> arch/mips/mips64 -> arch/mips/mips64/o32 (like we |
| 39 |
>>>>>>>>>> have /n32 and /n64 there), so that instead of having |
| 40 |
>>>>>>>>>> to unset them, we'd just have them set for the |
| 41 |
>>>>>>>>>> relevant real profiles. However, I'm not sure if this |
| 42 |
>>>>>>>>>> doesn't come with some pitfalls. |
| 43 |
>>>>>>>>> Blueness and I talked about this (proper n32 / n64 / |
| 44 |
>>>>>>>>> o32 defaults and forces/masks) in #gentoo-dev two or |
| 45 |
>>>>>>>>> three weeks ago; I thought we worked out the correct |
| 46 |
>>>>>>>>> modifications to profiles to get it right and he had |
| 47 |
>>>>>>>>> already pushed the fixes... ?? |
| 48 |
>>>>>> I can't see anything. Did you actually push them? What was |
| 49 |
>>>>>> decided as the plan for action? |
| 50 |
>>>>>> |
| 51 |
>>>>>>> I did not have time to get to them. I was going to play |
| 52 |
>>>>>>> with two different approaches. One is simply turning off |
| 53 |
>>>>>>> o32 at multilib/../n32 level, the other was to restructure |
| 54 |
>>>>>>> the profiles entirely and put o32, n32 and 64 on par, not |
| 55 |
>>>>>>> inherit from a hire level "default" profile. I'm leaning |
| 56 |
>>>>>>> towards that approach, but I'm worried it might play havoc |
| 57 |
>>>>>>> on our users. |
| 58 |
>>> Well i need to see the structure for your second approach to |
| 59 |
>>> understand what you have in mind. Perhaps the first option is the |
| 60 |
>>> safest and ensure some backwards compatibility with existing |
| 61 |
>>> mips32 users? |
| 62 |
>>> |
| 63 |
>>>> Yes it would be more backwards compat, but it is not semetrical. |
| 64 |
>>>> The regular (ie glibc) profiles would become: |
| 65 |
>>>> [1] default/linux/mips/13.0/o32 <-change [2] |
| 66 |
>>>> default/linux/mips/13.0/n32 [3] default/linux/mips/13.0/n64 [4] |
| 67 |
>>>> default/linux/mips/13.0/multilib/o32 <-change [5] |
| 68 |
>>>> default/linux/mips/13.0/multilib/n32 [6] |
| 69 |
>>>> default/linux/mips/13.0/multilib/n64 [7] |
| 70 |
>>>> default/linux/mips/13.0/mipsel/o32 <- change [8] |
| 71 |
>>>> default/linux/mips/13.0/mipsel/n32 [9] |
| 72 |
>>>> default/linux/mips/13.0/mipsel/n64 [10] |
| 73 |
>>>> default/linux/mips/13.0/mipsel/multilib/o32 <-change [11] |
| 74 |
>>>> default/linux/mips/13.0/mipsel/multilib/n32 [12] |
| 75 |
>>>> default/linux/mips/13.0/mipsel/multilib/n64 |
| 76 |
>> I think that if you symlink the following |
| 77 |
>> |
| 78 |
>> default/linux/mips/13.0/eapi -> default/linux/mips/13.0/o32/eapi |
| 79 |
>> default/linux/mips/13.0/parent -> default/linux/mips/13.0/o32/parent |
| 80 |
>> |
| 81 |
>> existing default/linux/mips/13.0/ users will be unaffected. But I am |
| 82 |
>> not sure if we are allowed to use symlinks (same thing for mipsel) |
| 83 |
>> |
| 84 |
>> If we can't avoid it then we can send the usual email to the lists |
| 85 |
>> informing users for the change. I believe it's not hard for them to |
| 86 |
>> figure out what changed and how to select the proper profile for their |
| 87 |
>> mips32 boxes. |
| 88 |
> |
| 89 |
> Let me test first the new profiles. I will put them on the |
| 90 |
> hardened-dev::profile overlay. I know they're not hardened, but we do |
| 91 |
> testing of big changes to profiles there. Then you can review what |
| 92 |
> I've done. |
| 93 |
> |
| 94 |
> I'm not sure about the sym links either. |
| 95 |
> |
| 96 |
|
| 97 |
This isn't going to work. The problem is that the above structure |
| 98 |
doesn't distinguish between mips/o32 and mips64/o32 (and equivalent el |
| 99 |
versions). Now mips64/o32 is funny, but possible: it would be o32 (a |
| 100 |
32-bit abi) on 64 bit arch/kernel, like ppc64-32ul. The structure is |
| 101 |
possible at the level of profile/arch, but it would mean a deep |
| 102 |
restructuring of default/linux/mips/13.0. |
| 103 |
|
| 104 |
I'm not sure we want to make such a deep change. The profiles we would |
| 105 |
present to the user would look like: |
| 106 |
|
| 107 |
[1] default/linux/mips/13.0/mips/o32 |
| 108 |
default/linux/mips/13.0/mips64/o32 <- distinguish the |
| 109 |
mips/o32 and mips64/o32 |
| 110 |
[2] default/linux/mips/13.0/mips64/n32 |
| 111 |
[3] default/linux/mips/13.0/mips64/n64 |
| 112 |
[4] default/linux/mips/13.0/multilib/o32 <- multilib is |
| 113 |
necessarily mips64 |
| 114 |
[5] default/linux/mips/13.0/multilib/n32 <- multilib is |
| 115 |
necessarily mips64 |
| 116 |
[6] default/linux/mips/13.0/multilib/n64 <- multilib is |
| 117 |
necessarily mips64 |
| 118 |
[7] default/linux/mips/13.0/mipsel/o32 |
| 119 |
default/linux/mips/13.0/mips64el/o32 <- distinguish the |
| 120 |
mipsel/o32 and mips64el/o32 |
| 121 |
[8] default/linux/mips/13.0/mips64el/n32 |
| 122 |
[9] default/linux/mips/13.0/mips64el/n64 |
| 123 |
[10] default/linux/mips/13.0/mipsel/multilib/o32 <- multilib is |
| 124 |
necessarily mips64el |
| 125 |
[11] default/linux/mips/13.0/mipsel/multilib/n32 <- multilib is |
| 126 |
necessarily mips64el |
| 127 |
[12] default/linux/mips/13.0/mipsel/multilib/n64 <- multilib is |
| 128 |
necessarily mips64el |
| 129 |
|
| 130 |
No need to touch the rest. |
| 131 |
[13] hardened/linux/musl/mips |
| 132 |
[14] hardened/linux/musl/mips/mipsel |
| 133 |
[15] default/linux/uclibc/mips |
| 134 |
[16] hardened/linux/uclibc/mips |
| 135 |
[17] default/linux/uclibc/mips/mipsel |
| 136 |
[18] hardened/linux/uclibc/mips/mipsel |
| 137 |
|
| 138 |
|
| 139 |
Maybe we just don't want to support mips64/o32? I'm starting to lean |
| 140 |
towards Ian's simple but asymmetric solution of turning off o32 in the |
| 141 |
inheriting profiles. |
| 142 |
|
| 143 |
|
| 144 |
-- |
| 145 |
Anthony G. Basile, Ph.D. |
| 146 |
Gentoo Linux Developer [Hardened] |
| 147 |
E-Mail : blueness@g.o |
| 148 |
GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA |
| 149 |
GnuPG ID : F52D4BBA |
Archives