Ned Deily <n...@python.org> added the comment:
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. ---------- priority: release blocker -> normal resolution: -> fixed stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31354> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
