public inbox for gentoo-mips@lists.gentoo.org
 help / color / mirror / Atom feed
From: Markos Chandras <hwoarang@gentoo.org>
To: "Ian Stakenvicius" <axs@gentoo.org>, "Michał Górny" <mgorny@gentoo.org>
Cc: gentoo-mips@lists.gentoo.org, multilib@gentoo.org
Subject: Re: [gentoo-mips] multilib problems on mips64 profiles
Date: Wed, 17 Sep 2014 18:50:53 +0100	[thread overview]
Message-ID: <5419C9FD.6060106@gentoo.org> (raw)
In-Reply-To: <54198ECB.7010803@gentoo.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

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 
>> <hwoarang@gentoo.org> 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?

> 
> Is it just a matter of documenting the full map of exactly what 
> multilib profile should be forced-on and default-on in each, and
> then either adjusting profiles if they don't match up OR allowing
> users to select the correct profile for what they want?
> 
> For example, i'm not understanding why n64 -should- be enabled by 
> default on the mips64/n32 profile??  If you wanted more than
> {n,o}32 shouldn't you be choosing the base mips64 profile?
> 
> 
Perhaps it should not but neither should o32

- -- 
Regards,
Markos Chandras
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQF8BAEBCgBmBQJUGcn9XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGRDlGMzA4MUI2MzBDODQ4RDBGOEYxMjQx
RjEwRUQ0QjgxREVCRjE5AAoJEB8Q7UuB3r8ZjSIH/3g0y2CTrZrJtmo7n9XvUIBK
F35WepF3zkkKE6BFxNF1qbLE7OrIUbhERZzn3bDdEz/9vBlE/oMfrV+M2tbdMX77
rohS5jvAQN5F2TYhdtJBWrDV1PRidfTIx+qAL1IFIw+xNA96Wzyy+TveqRYb6BG5
jqIHvyNdFu8yZKGp5OEbJgz9Jk/d4bB4cDPkIKbZODWl2aD6iuVO6hvSveB9WQrd
Rmair7kUi27Drrr8aNd0pt9tF0PFoFM1+Tt1axLXWDHkx3gLsqCEg7fXSKHsoUGO
kJH8WcWhJiYhK4nN+NJuaBm35UKFpZMY1ac5iA8UoR92QN00NqAeiMa+vMt9u7s=
=wYWx
-----END PGP SIGNATURE-----


  parent reply	other threads:[~2014-09-17 17:51 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-13  9:47 [gentoo-mips] multilib problems on mips64 profiles Markos Chandras
2014-09-13 13:54 ` Anthony G. Basile
2014-09-17  8:31 ` Michał Górny
     [not found]   ` <54198ECB.7010803@gentoo.org>
2014-09-17 17:50     ` Markos Chandras [this message]
2014-09-17 19:13       ` Anthony G. Basile
2014-09-17 19:41         ` Markos Chandras
2014-09-17 19:52           ` Anthony G. Basile
2014-09-17 20:13             ` Markos Chandras
2014-09-17 20:19               ` Anthony G. Basile
2014-09-21 21:55                 ` Anthony G. Basile
2014-09-21 22:45                   ` Matt Turner
2014-09-21 22:53                     ` Anthony G. Basile
2014-09-21 22:53                   ` Joshua Kinard
2014-09-22  1:11                     ` Anthony G. Basile
2014-09-22  1:12                       ` Anthony G. Basile
2014-09-22  1:29                         ` Joshua Kinard
2014-09-22 10:39                           ` Anthony G. Basile
2014-09-22  1:49                       ` Joshua Kinard
2014-09-22 10:53                         ` Anthony G. Basile

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5419C9FD.6060106@gentoo.org \
    --to=hwoarang@gentoo.org \
    --cc=axs@gentoo.org \
    --cc=gentoo-mips@lists.gentoo.org \
    --cc=mgorny@gentoo.org \
    --cc=multilib@gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox