[Distutils] draft PEP: manylinux2

[Mark Williams]

On Mon, Feb 05, 2018 at 08:51:03PM -0800, Mark Williams wrote:
> On Sat, Feb 03, 2018 at 12:11:51AM -0800, Nathaniel Smith wrote:
> >
> > We can and should use newer compiler versions than that, and probably
> > upgrade them again over the course of the image's lifespan, so let's
> > just drop the version numbers from the PEP entirely. (Maybe s/6.9/6/
> > as well for the same reason.)
> 
> Wouldn't upgrading compiler versions potentially imply a change in
> libgcc symbol versions?  If so, that would either require the PEP be
> updated for each new compiler, or the removal of libgcc from the
> library whitelist.
> 
> I may be overly paranoid about this.

I was overly paranoid about it :)

Geoffrey Thomas helped to confirm that devtoolset-7 does the Right
Thing.  Its libgcc_s.so is actually the following linker script:

# cat /opt/rh/devtoolset-7/root/usr/lib/gcc/x86_64-redhat-linux/7/libgcc_s.so
/* GNU ld script
   Use the shared library, but some functions are only in
   the static library, so try that secondarily.  */
OUTPUT_FORMAT(elf64-x86-64)
GROUP ( /lib64/libgcc_s.so.1 libgcc.a )

The GROUP command instructs ld to search for GCC symbols in the
system's libgcc_s.so first; if they're present there, the resulting
binary will load them from it at runtime, and the binary will match
the ABI policy described in the PEP.  If the binary requires newer
symbols that aren't present in the system's libgcc_s.so, ld will
statically link them in from its interal libgcc.a.  This result will
also match the ABI policy, in that it will either depend only on the
subset of symbols available in CentOS 6's default libgcc_s.so or none
at all.

See the ld documentation for an explanation of GROUP:

https://sourceware.org/binutils/docs/ld/File-Commands.html

--
  Mark Williams
  mrw at twistedmatrix.com