1 |
-----BEGIN PGP SIGNED MESSAGE----- |
2 |
Hash: SHA512 |
3 |
|
4 |
On 09/17/2014 08:13 PM, Anthony G. Basile wrote: |
5 |
> On 09/17/14 13:50, Markos Chandras wrote: On 09/17/2014 02:38 PM, |
6 |
> Ian Stakenvicius wrote: |
7 |
>>>> On 17/09/14 04:31 AM, Micha³ Górny wrote: |
8 |
>>>>> Dnia 2014-09-13, o godz. 10:47:49 Markos Chandras |
9 |
>>>>> <hwoarang@g.o> napisa³(a): |
10 |
>>>> |
11 |
>>>>>> Here is some weirdness with eg mips64/n32 multilib |
12 |
>>>>>> profile when trying a world update |
13 |
>>>>>> |
14 |
>>>>>> [ebuild U ] sys-devel/libtool-2.4.2-r1:2 [2.4.2:2] |
15 |
>>>>>> USE="-static-libs {-test} -vanilla" ABI_MIPS="(n32%*) |
16 |
>>>>>> o32%* -n64%" 0 kB |
17 |
>>>>>> |
18 |
>>>>>> As you can see n32 and o32 are enabled but n64 is not. |
19 |
>>>>>> Obviously this is not full mips64 multilib. This is |
20 |
>>>>>> probably due the portage profile stacking/inheritance |
21 |
>>>>>> problems on mips64, where the mips64/multilib profiles |
22 |
>>>>>> inherit the default o32 one. Michal (multilib CC'd) can |
23 |
>>>>>> provide more information on what exactly goes wrong since |
24 |
>>>>>> he understands the problem better than me. Michal also |
25 |
>>>>>> said that on amd64, the multilib profiles defaults to |
26 |
>>>>>> 64-bit only. I believe this contradicts with what someone |
27 |
>>>>>> expects from MIPS64 where all three ABIs need to be |
28 |
>>>>>> present *by default* unless you override the ABI_MIPS |
29 |
>>>>>> variable in make.conf. Correct? |
30 |
>>>> |
31 |
>>>>> Well, long story short we inherit from 'top-level' profile |
32 |
>>>>> that has some o32 settings inside. I believe that it could |
33 |
>>>>> be saner to move those from arch/mips/mips64 -> |
34 |
>>>>> arch/mips/mips64/o32 (like we have /n32 and /n64 there), so |
35 |
>>>>> that instead of having to unset them, we'd just have them |
36 |
>>>>> set for the relevant real profiles. |
37 |
>>>> |
38 |
>>>>> However, I'm not sure if this doesn't come with some |
39 |
>>>>> pitfalls. |
40 |
>>>> |
41 |
>>>> |
42 |
>>>> Blueness and I talked about this (proper n32 / n64 / o32 |
43 |
>>>> defaults and forces/masks) in #gentoo-dev two or three weeks |
44 |
>>>> ago; I thought we worked out the correct modifications to |
45 |
>>>> profiles to get it right and he had already pushed the |
46 |
>>>> fixes... ?? |
47 |
> |
48 |
> I can't see anything. Did you actually push them? What was decided |
49 |
> as the plan for action? |
50 |
> |
51 |
>> I did not have time to get to them. I was going to play with |
52 |
>> two different approaches. One is simply turning off o32 at |
53 |
>> multilib/../n32 level, the other was to restructure the profiles |
54 |
>> entirely and put o32, n32 and 64 on par, not inherit from a hire |
55 |
>> level "default" profile. I'm leaning towards that approach, but |
56 |
>> I'm worried it might play havoc on our users. |
57 |
> |
58 |
|
59 |
Well i need to see the structure for your second approach to |
60 |
understand what you have in mind. Perhaps the first option is the |
61 |
safest and ensure some backwards compatibility with existing mips32 users? |
62 |
|
63 |
- -- |
64 |
Regards, |
65 |
Markos Chandras |
66 |
-----BEGIN PGP SIGNATURE----- |
67 |
Version: GnuPG v2 |
68 |
|
69 |
iQF8BAEBCgBmBQJUGeP/XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w |
70 |
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGRDlGMzA4MUI2MzBDODQ4RDBGOEYxMjQx |
71 |
RjEwRUQ0QjgxREVCRjE5AAoJEB8Q7UuB3r8Z5msH/1YBYb9trZYGrkXkR0FIcx9Y |
72 |
ltJ8PL7jGG1B4NO0PJJpwehMSsxFbkpq3VT9ahrVq4+K58/3XRDmoWGEsWpBIo3o |
73 |
KHCmCOoC2KPmGFEXofKsD7iAlb83X5/KsHVhHioUy/5D7JMf4PrPLPjkMtRFU0oR |
74 |
h9+hah+3tSMO5QUh4blXnYJ4LeE298GjPJMwPtMlhx4uRUyXeRhUfuINzdf9uMBV |
75 |
FFHfJKOfsr9aizUpJxza/Wph+IA+NVGTCekZzWQ6gSZW+MxiF3mAeLFj6I6g+0lI |
76 |
Ga8+Z1Bs/JM7P4csLJ2Sp+ccgaIGXg6xU/BtlpKyJl745mpBAt58w17762+ivjs= |
77 |
=PqPy |
78 |
-----END PGP SIGNATURE----- |