Re: [gentoo-dev] Introduce ppc64le architecture into gentoo ! please share your comments

[Mike Frysinger <vapier@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 2013 bytes --]

On 11 Aug 2015 10:45, Anthony G. Basile wrote:
> On 8/11/15 10:33 AM, Ian Stakenvicius wrote:
> > On 11/08/15 06:11 AM, Leno Hou wrote:
> >> I think ppc64le would become popular,
> >> https://en.wikipedia.org/wiki/Ppc64.
> >>
> >> 1. enable porting x86 Linux based application with minimal effort.
> >>   2. Some PowerPC user, little endian apparently feels cheap, wrong,
> >> and PCish. 3. Other distrbutions like Ubuntu, Redhat and SUSE
> >> already support little endian in powerpc.
> >
> > In terms of the codepaths, what's different between ppc64le vs ppc64,
> > and ppc64le vs amd64 ?  Obviously kernels will differ, but in terms of
> > C/C++/other compiled source code what needs to change?
> >
> > If all this needs is its own profile for a CHOST/CBUILD specification
> > and it can leverage an existing keyword, then this should be rather
> > simple to implement yes?
> 
> We would leverage this on ppc64 keyword.  It is a bit dangerous to claim 
> that a pkg stable on ppc64 is stable on ppc64le, but we would live with 
> that risk.  Ideally you should test on both.  The situation is analogous 
> to mips where there are many different ISAs and both be and le.  It is 
> one of the reasons mips is hard to move back into stable.  But having 
> stable keywords is really nice when it comes to building and maintaining 
> stages and keeping base pkgs versions in sync with the other arches.  
> For this reason, I would even been in favor of restoring stable mips 
> with the understanding that "stable" carries something of a risk when 
> crossing the be/le boundry, or the mips I vs mips III, or 32 vs 64, etc.

yes, we should just re-use the existing KEYWORDS and control the endian
differences via profiles.  it's how other arches (mips, ppc, arm, arm64)
are handled currently.

note: people have already built Gentoo for ppc little endian, but that
tends to only be used in embedded setups, so the builds don't get published
like other arches as stages.
-mike

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]