| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA512 |
| 3 |
|
| 4 |
On 09/17/2014 02:38 PM, Ian Stakenvicius wrote: |
| 5 |
> On 17/09/14 04:31 AM, Micha³ Górny wrote: |
| 6 |
>> Dnia 2014-09-13, o godz. 10:47:49 Markos Chandras |
| 7 |
>> <hwoarang@g.o> napisa³(a): |
| 8 |
> |
| 9 |
>>> Here is some weirdness with eg mips64/n32 multilib profile |
| 10 |
>>> when trying a world update |
| 11 |
>>> |
| 12 |
>>> [ebuild U ] sys-devel/libtool-2.4.2-r1:2 [2.4.2:2] |
| 13 |
>>> USE="-static-libs {-test} -vanilla" ABI_MIPS="(n32%*) o32%* |
| 14 |
>>> -n64%" 0 kB |
| 15 |
>>> |
| 16 |
>>> As you can see n32 and o32 are enabled but n64 is not. |
| 17 |
>>> Obviously this is not full mips64 multilib. This is probably |
| 18 |
>>> due the portage profile stacking/inheritance problems on |
| 19 |
>>> mips64, where the mips64/multilib profiles inherit the default |
| 20 |
>>> o32 one. Michal (multilib CC'd) can provide more information on |
| 21 |
>>> what exactly goes wrong since he understands the problem better |
| 22 |
>>> than me. Michal also said that on amd64, the multilib profiles |
| 23 |
>>> defaults to 64-bit only. I believe this contradicts with what |
| 24 |
>>> someone expects from MIPS64 where all three ABIs need to be |
| 25 |
>>> present *by default* unless you override the ABI_MIPS variable |
| 26 |
>>> in make.conf. Correct? |
| 27 |
> |
| 28 |
>> Well, long story short we inherit from 'top-level' profile that |
| 29 |
>> has some o32 settings inside. I believe that it could be saner |
| 30 |
>> to move those from arch/mips/mips64 -> arch/mips/mips64/o32 (like |
| 31 |
>> we have /n32 and /n64 there), so that instead of having to unset |
| 32 |
>> them, we'd just have them set for the relevant real profiles. |
| 33 |
> |
| 34 |
>> However, I'm not sure if this doesn't come with some pitfalls. |
| 35 |
> |
| 36 |
> |
| 37 |
> Blueness and I talked about this (proper n32 / n64 / o32 defaults |
| 38 |
> and forces/masks) in #gentoo-dev two or three weeks ago; I thought |
| 39 |
> we worked out the correct modifications to profiles to get it right |
| 40 |
> and he had already pushed the fixes... ?? |
| 41 |
|
| 42 |
I can't see anything. Did you actually push them? What was decided as |
| 43 |
the plan for action? |
| 44 |
|
| 45 |
> |
| 46 |
> Is it just a matter of documenting the full map of exactly what |
| 47 |
> multilib profile should be forced-on and default-on in each, and |
| 48 |
> then either adjusting profiles if they don't match up OR allowing |
| 49 |
> users to select the correct profile for what they want? |
| 50 |
> |
| 51 |
> For example, i'm not understanding why n64 -should- be enabled by |
| 52 |
> default on the mips64/n32 profile?? If you wanted more than |
| 53 |
> {n,o}32 shouldn't you be choosing the base mips64 profile? |
| 54 |
> |
| 55 |
> |
| 56 |
Perhaps it should not but neither should o32 |
| 57 |
|
| 58 |
- -- |
| 59 |
Regards, |
| 60 |
Markos Chandras |
| 61 |
-----BEGIN PGP SIGNATURE----- |
| 62 |
Version: GnuPG v2 |
| 63 |
|
| 64 |
iQF8BAEBCgBmBQJUGcn9XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w |
| 65 |
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGRDlGMzA4MUI2MzBDODQ4RDBGOEYxMjQx |
| 66 |
RjEwRUQ0QjgxREVCRjE5AAoJEB8Q7UuB3r8ZjSIH/3g0y2CTrZrJtmo7n9XvUIBK |
| 67 |
F35WepF3zkkKE6BFxNF1qbLE7OrIUbhERZzn3bDdEz/9vBlE/oMfrV+M2tbdMX77 |
| 68 |
rohS5jvAQN5F2TYhdtJBWrDV1PRidfTIx+qAL1IFIw+xNA96Wzyy+TveqRYb6BG5 |
| 69 |
jqIHvyNdFu8yZKGp5OEbJgz9Jk/d4bB4cDPkIKbZODWl2aD6iuVO6hvSveB9WQrd |
| 70 |
Rmair7kUi27Drrr8aNd0pt9tF0PFoFM1+Tt1axLXWDHkx3gLsqCEg7fXSKHsoUGO |
| 71 |
kJH8WcWhJiYhK4nN+NJuaBm35UKFpZMY1ac5iA8UoR92QN00NqAeiMa+vMt9u7s= |
| 72 |
=wYWx |
| 73 |
-----END PGP SIGNATURE----- |
Archives