| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA512 |
| 3 |
|
| 4 |
On 09/17/2014 08:52 PM, Anthony G. Basile wrote: |
| 5 |
> On 09/17/14 15:41, Markos Chandras wrote: On 09/17/2014 08:13 PM, |
| 6 |
> Anthony G. Basile wrote: |
| 7 |
>>>> On 09/17/14 13:50, Markos Chandras wrote: On 09/17/2014 02:38 |
| 8 |
>>>> PM, Ian Stakenvicius wrote: |
| 9 |
>>>>>>> On 17/09/14 04:31 AM, Micha³ Górny wrote: |
| 10 |
>>>>>>>> Dnia 2014-09-13, o godz. 10:47:49 Markos Chandras |
| 11 |
>>>>>>>> <hwoarang@g.o> napisa³(a): |
| 12 |
>>>>>>>>> Here is some weirdness with eg mips64/n32 multilib |
| 13 |
>>>>>>>>> profile when trying a world update |
| 14 |
>>>>>>>>> |
| 15 |
>>>>>>>>> [ebuild U ] sys-devel/libtool-2.4.2-r1:2 |
| 16 |
>>>>>>>>> [2.4.2:2] USE="-static-libs {-test} -vanilla" |
| 17 |
>>>>>>>>> ABI_MIPS="(n32%*) o32%* -n64%" 0 kB |
| 18 |
>>>>>>>>> |
| 19 |
>>>>>>>>> As you can see n32 and o32 are enabled but n64 is |
| 20 |
>>>>>>>>> not. Obviously this is not full mips64 multilib. |
| 21 |
>>>>>>>>> This is probably due the portage profile |
| 22 |
>>>>>>>>> stacking/inheritance problems on mips64, where the |
| 23 |
>>>>>>>>> mips64/multilib profiles inherit the default o32 |
| 24 |
>>>>>>>>> one. Michal (multilib CC'd) can provide more |
| 25 |
>>>>>>>>> information on what exactly goes wrong since he |
| 26 |
>>>>>>>>> understands the problem better than me. Michal |
| 27 |
>>>>>>>>> also said that on amd64, the multilib profiles |
| 28 |
>>>>>>>>> defaults to 64-bit only. I believe this contradicts |
| 29 |
>>>>>>>>> with what someone expects from MIPS64 where all |
| 30 |
>>>>>>>>> three ABIs need to be present *by default* unless |
| 31 |
>>>>>>>>> you override the ABI_MIPS variable in make.conf. |
| 32 |
>>>>>>>>> Correct? |
| 33 |
>>>>>>>> Well, long story short we inherit from 'top-level' |
| 34 |
>>>>>>>> profile that has some o32 settings inside. I believe |
| 35 |
>>>>>>>> that it could be saner to move those from |
| 36 |
>>>>>>>> arch/mips/mips64 -> arch/mips/mips64/o32 (like we |
| 37 |
>>>>>>>> have /n32 and /n64 there), so that instead of having |
| 38 |
>>>>>>>> to unset them, we'd just have them set for the |
| 39 |
>>>>>>>> relevant real profiles. However, I'm not sure if this |
| 40 |
>>>>>>>> doesn't come with some pitfalls. |
| 41 |
>>>>>>> |
| 42 |
>>>>>>> Blueness and I talked about this (proper n32 / n64 / |
| 43 |
>>>>>>> o32 defaults and forces/masks) in #gentoo-dev two or |
| 44 |
>>>>>>> three weeks ago; I thought we worked out the correct |
| 45 |
>>>>>>> modifications to profiles to get it right and he had |
| 46 |
>>>>>>> already pushed the fixes... ?? |
| 47 |
>>>> I can't see anything. Did you actually push them? What was |
| 48 |
>>>> decided as the plan for action? |
| 49 |
>>>> |
| 50 |
>>>>> I did not have time to get to them. I was going to play |
| 51 |
>>>>> with two different approaches. One is simply turning off |
| 52 |
>>>>> o32 at multilib/../n32 level, the other was to restructure |
| 53 |
>>>>> the profiles entirely and put o32, n32 and 64 on par, not |
| 54 |
>>>>> inherit from a hire level "default" profile. I'm leaning |
| 55 |
>>>>> towards that approach, but I'm worried it might play havoc |
| 56 |
>>>>> on our users. |
| 57 |
> Well i need to see the structure for your second approach to |
| 58 |
> understand what you have in mind. Perhaps the first option is the |
| 59 |
> safest and ensure some backwards compatibility with existing |
| 60 |
> mips32 users? |
| 61 |
> |
| 62 |
>> Yes it would be more backwards compat, but it is not semetrical. |
| 63 |
> |
| 64 |
>> The regular (ie glibc) profiles would become: |
| 65 |
> |
| 66 |
>> [1] default/linux/mips/13.0/o32 <-change [2] |
| 67 |
>> default/linux/mips/13.0/n32 [3] default/linux/mips/13.0/n64 [4] |
| 68 |
>> default/linux/mips/13.0/multilib/o32 <-change [5] |
| 69 |
>> default/linux/mips/13.0/multilib/n32 [6] |
| 70 |
>> default/linux/mips/13.0/multilib/n64 [7] |
| 71 |
>> default/linux/mips/13.0/mipsel/o32 <- change [8] |
| 72 |
>> default/linux/mips/13.0/mipsel/n32 [9] |
| 73 |
>> default/linux/mips/13.0/mipsel/n64 [10] |
| 74 |
>> default/linux/mips/13.0/mipsel/multilib/o32 <-change [11] |
| 75 |
>> default/linux/mips/13.0/mipsel/multilib/n32 [12] |
| 76 |
>> default/linux/mips/13.0/mipsel/multilib/n64 |
| 77 |
|
| 78 |
I think that if you symlink the following |
| 79 |
|
| 80 |
default/linux/mips/13.0/eapi -> default/linux/mips/13.0/o32/eapi |
| 81 |
default/linux/mips/13.0/parent -> default/linux/mips/13.0/o32/parent |
| 82 |
|
| 83 |
existing default/linux/mips/13.0/ users will be unaffected. But I am |
| 84 |
not sure if we are allowed to use symlinks (same thing for mipsel) |
| 85 |
|
| 86 |
If we can't avoid it then we can send the usual email to the lists |
| 87 |
informing users for the change. I believe it's not hard for them to |
| 88 |
figure out what changed and how to select the proper profile for their |
| 89 |
mips32 boxes. |
| 90 |
|
| 91 |
- -- |
| 92 |
Regards, |
| 93 |
Markos Chandras |
| 94 |
-----BEGIN PGP SIGNATURE----- |
| 95 |
Version: GnuPG v2 |
| 96 |
|
| 97 |
iQF8BAEBCgBmBQJUGetvXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w |
| 98 |
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGRDlGMzA4MUI2MzBDODQ4RDBGOEYxMjQx |
| 99 |
RjEwRUQ0QjgxREVCRjE5AAoJEB8Q7UuB3r8ZA2UH/j9O3h3cuvoFEJnRFvGOoLHF |
| 100 |
c0tQykVpAjcJm4G6fEDLS1+soRl+U8PENxM3cnqEeLWsz9qRTyB9QJCF6s2cg6tr |
| 101 |
/7eUWn3OnFD5jSW9A16BiX0vpKGCdJFz30HDN6zFJpuOj2jhKOeZplNgDICQtJr2 |
| 102 |
yBsv7q9rN99MQc/hEQK8tvffIibrVNlNIyKb6YoRuzuPycu5v6thiTFwPSyWh8Q/ |
| 103 |
qqdokI024Qg4DqGhwSd1puq2iISaT4xH2Fn6ZgR0pyHFwy0bQx9IRNe0cjZfP2yJ |
| 104 |
biCZqcG0S5VOFv161FbnA3EyutuFIzRJs60EqnyjkezlDvXJqNOmTdePYdS5/T4= |
| 105 |
=TPCw |
| 106 |
-----END PGP SIGNATURE----- |
Archives