Message281332
| Author |
gregory.p.smith |
| Recipients |
alecsandru.patrascu, benjamin.peterson, gregory.p.smith, koobs, larry, ned.deily, pitrou, python-dev, sjt |
| Date |
2016年11月21日.08:19:52 |
| SpamBayes Score |
-1.0 |
| Marked as misclassified |
Yes |
| Message-id |
<1479716392.64.0.772049305738.issue28032@psf.upfronthosting.co.za> |
| In-reply-to |
| Content |
This is no longer a release blocker as --with-lto is not enabled by default by --enable-optimizations since my commits in September.
Regarding --with-lto itself segfaulting... Fixing compiler+linker toolchains is beyond what CPython itself should do. But the reason the flag remains named "optimizations" is that it is fair for us to include --with-lto or other future build time optimization in known good configurations detected by the autoconf configure.ac in the future if desired.
I do not think there is anything more for us to do here. We should explicitly _not_ try to add smarts to --with-lto itself as to whether we believe it will build a broken binary or not. |
|