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 m...@twistedmatrix.com _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig