<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 24 March 2017 at 05:00, Leonardo Bianconi <span dir="ltr"><<a href="mailto:leonardo.bianconi@eldorado.org.br" target="_blank">leonardo.bianconi@eldorado.org.br</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi all!<br>
<br>
I have been discussed the creation of a PEP, that describes how to create wheel<br>
files for the PPC64le architecture on wheel-builders<br>
(<a href="https://mail.python.org/pipermail/wheel-builders/" rel="noreferrer" target="_blank">https://mail.python.org/<wbr>pipermail/wheel-builders/</a>) since January<br>
(<a href="https://mail.python.org/pipermail/wheel-builders/2017-January/000245.html" rel="noreferrer" target="_blank">https://mail.python.org/<wbr>pipermail/wheel-builders/2017-<wbr>January/000245.html</a>).<br></blockquote><div><br></div><div>Thanks Leonardo!<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
As all discussion from that list are done, the next step is it be reviewed<br>
here, and then create a draft on github,</blockquote><div><br></div><div>You can submit the PR to the PEPs repo whenever you're ready - it's actually handy to have the PEP number assigned fairly early as a convenient reference for the proposal.<br></div><div><br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
The ``manylinux3`` policy<br>
=========================<br>
<br>
Based on PEP 513 [1]_, the policy follows the same rules and library<br>
dependencies, but with the following versions for backward compatibility<br>
and base Operational System:<br>
<br>
* Backward compatibility versions:<br>
    GLIBC <= 2.17<br>
    CXXABI <= 1.3.7<br>
    GLIBCXX <= 3.4.9<br>
    GCC <= 4.8.5<br>
<br>
* Base Operational System:<br>
  The stock O.S. release need to be the CentOS 7 [4]_, as it is the first<br>
  CentOS release available for PowerPC64 little endian.<br>
<br>
The tag version for ppc64le architecture starts with 3 (``manylinux3_``), as it<br>
is supposed to be the version to match the CentOS 7 [4]_ in the future of the<br>
tag for x86_64/i686 architecture. There is the possibility of both tags diverge<br>
until it reaches the version 3, then a new PEP may be create to converge<br>
both to the manylinux baseline.<br></blockquote><div><br></div><div>Having manylinuxN consistently align with CentOS(N+4) seems reasonable to me for simplicity's sake, but there should be a discussion in the PEP around how that aligns with ppc64le support on other LTS distros (mainly Debian and Ubuntu).<br><br></div><div>Given the relative dates involved, I'd expect manylinux-style binaries compiled on CentOS 7 to also work on Ubuntu 14.04, 16.04 and Debian 8, but the PEP should explicitly confirm that the nominated symbol versions above are available on all of those distros.<br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

Compilation of Compliant Wheels<br>
==============================<wbr>=<br>
<br>
As compiling wheel files that meet the ``manylinux3`` standard for PowerPC64<br>
little endian requires a specific Linux distro and version, the following tool<br>
is provided:<br>
<br>
<br>
Docker Image (Will be implemented when CentOS be available on Docker)<br>
------------<br>
<br>
The Docker Image is based on CentOS 7 [4]_, which is the first PowerPC 64<br>
little endian CentOS release. The Image contains all necessary tools in the<br>
requested version to build wheel files (gcc, g++ and gfortran 4.8.5).<br></blockquote><div><br></div><div>These seem to be present now: <a href="https://hub.docker.com/r/ppc64le/centos/tags/">https://hub.docker.com/r/ppc64le/centos/tags/</a><br></div><div><br></div><div>I'm not clear on the provenance of the 'ppc64le' user account though, so I've asked for clarification: ttps://<a href="http://twitter.com/ncoghlan_dev/status/845099237117329408">twitter.com/ncoghlan_dev/status/845099237117329408</a><br></div><div><br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Platform detection for Installers<br>
==============================<wbr>===<br>
<br>
The platform detection is almost the same as described in PEP 513 [1]_, but<br>
with the following proposed change:<br>
<br>
1. Add the platform ppc64le in the platform list as a compatible one:<br>
   [``linux-x86_64``, ``linux-i686``, ``linux-ppc64le``]<br>
2. Add an if to switch architecture and consider the correct version of the<br>
   GLIBC on ``return have_compatible_glibc(2, 5)``.<br></blockquote><div><br></div><div>I don't think is quite that simple, as installers need to be able to figure out:<br><br></div><div>- on manylinux3 compatible platforms, prefer manylinux3 to manylinux1<br></div><div>- on manylinux3 *in*compatible platforms, only consider manylinux1<br><br></div><div>And that means asking the question: when combined with the option of the distro-provided `_manylinux` module, is "have_compatible_glibc(2, 5) and not have_compatible_glibc(2, 17)" an adequate check for the latter case? (My inclination is to say "yes", but it would be helpful to have some more concrete data on glibc versions in different distros of interest)<br></div><div></div><div></div><div><br>Beyond that, I think the main open question would be: do we go ahead and
 define the full `manylinux3` specification now? CentOS 7+, Ubuntu 
14.04+, Debian 8+ compatibility still covers a *lot* of distros and deployments, and 
doing so means folks can bring the latest versions of gcc to bear on their code, 
rather than being limited to the last version that was made available for RHEL/CentOS 5 (gcc 4.8).<br><br></div><div>Going down that path would also means things would be simpler on the PyPI front - it could just allow manylinux3 for any architecture and let installers decide whether or not to use them.<br></div><div><br></div></div>Cheers,<br></div><div class="gmail_extra">Nick.<br clear="all"></div><div class="gmail_extra"><br>-- <br><div class="gmail_signature">Nick Coghlan   |   <a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>   |   Brisbane, Australia</div>
</div></div>