This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author ned.deily
Recipients cstratak, gregory.p.smith, ned.deily, octavian.soldea, vstinner
Date 2018-12-09.09:08:30
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1544346510.88.0.788709270274.issue31354@psf.upfronthosting.co.za>
In-reply-to
Content
OK, I think we are in better shape for 3.6.8 now.  I've merged the backports to 3.6 of Issue28015 / PR 9908 (LTO with clang) and Issue35351 / PR 10797 (prevent LTO CFLAGS leakage into distutils).  So, at the moment, master, 3.7, and 3.6 should behave the same in this area, although I'm a little bit leery of having all this backporting just before 3.6 stops accepting bugfixes.  As far as I can tell, what remains is resolving Issue35257 (prevent LTO LDFLAGS leakage into distutils).

>Side note on your comment: The compiler used (CC) also seems to leak
>into distutils instead of the system default CC, on linux with
>'python3 setup.py build'.

Yes, it does by design as do many other of the common build Makefile / environment variables.  The point I was trying to make applies more to binary distributions of Python, like with the python.org macOS installer.  In cases like that, the binary distribution is designed to install and run on multiple OS versions and that means that the compiler, and OS version for that matter, used to build the python executable and standard library extension modules are often very different from those on the end user's system when building third-party extension modules.
History
Date User Action Args
2018-12-09 09:08:30ned.deilysetrecipients: + ned.deily, gregory.p.smith, vstinner, cstratak, octavian.soldea
2018-12-09 09:08:30ned.deilysetmessageid: <1544346510.88.0.788709270274.issue31354@psf.upfronthosting.co.za>
2018-12-09 09:08:30ned.deilylinkissue31354 messages
2018-12-09 09:08:30ned.deilycreate