configure --with-optimizations is failing on the Debian --with-optimizations buildbot:

http://buildbot.python.org/all/builders/AMD64%20Debian%20PGO%203.x/builds/2448/steps/compile/logs/stdio

The compiled python is segfaulting when it goes to run the interpreter to build modules via setup.py.

this passes manually on ubuntu 16.04.  debian jessie 8.5 is failing here.  older gcc 4.9.2 toolchain.

i suspect --with-lto is not a good thing to enable by default everywhere.

configure.ac should be updated to exclude --with-lto in more situations than just Darwin.  we also know it doesn't work with clang as our configure and makefile are today.  so start with a conditional on gcc version being at least 5.4 (which is what ubuntu 16.04 ships with)?  or is it related to the binutils (ld) version when gcc is present?  or both.  LTO is a maze of twisty passages.

To lower this from "release blocker" we need to make --with-optimizations not enable --with-lto anywhere it is likely to fail.

Can we just split --with-optimizations into --with-pgo and --with-lto, and let users choose whichever combination they want?

That is effectively what this devolves to.  i'm going to try "gcc and gcc > 5.4" implies --with-lto as part of --with-optimizations for now.  but if that causes problems, i'll just remove the --with-lto implication from --with-optimizations entirely.

New changeset b77465544f28 by Gregory P. Smith in branch '3.5':
issue28032: never imply --with-lto as part of --with-optimizations.
https://hg.python.org/cpython/rev/b77465544f28

New changeset 4a50d87808a6 by Gregory P. Smith in branch 'default':
issue28032: never imply --with-lto as part of --with-optimizations.
https://hg.python.org/cpython/rev/4a50d87808a6

New changeset 7e89469e4342 by Gregory P. Smith in branch '2.7':
issue28032: never imply --with-lto as part of --with-optimizations.
https://hg.python.org/cpython/rev/7e89469e4342

Could we please:

a) Rename 'optimizations' to 'pgo' or 'profiled'
b) Use enable/disable instead of with/without. The former is used for toggling program features, the latter is used for external dependencies [1][2][3]

Yes Python's configure / autofoo isn't the paragon of conventions, consistency or elegance, but it would be fantastic to make the job of bringing it to (or arguing for) a more standards-oriented state moving forward easier rather than harder.

[1] https://www.gnu.org/software/autoconf/manual/autoconf-2.66/html_node/Package-Options.html
[2] https://www.gnu.org/software/autoconf/manual/autoconf-2.66/html_node/External-Software.html
[3] https://autotools.io/autoconf/arguments.html

I also invoke PEP20 (explicit > implicit) in favour of renaming the option :]

The configure flag has been renamed to --enable-optimizations in the following commits for 3,5, 3.6, default, & 2.7 branches (everywhere it exists):

remote: notified python-checkins@python.org of incoming changeset c0ea81315fb6
remote: notified python-checkins@python.org of incoming changeset 58c1a49a10b4
remote: notified python-checkins@python.org of incoming changeset 11cacf9f9a33
remote: notified python-checkins@python.org of incoming changeset 0d2b42344ae5
remote: notified python-checkins@python.org of incoming changeset 2d1d70b53376
remote: notified python-checkins@python.org of incoming changeset d5ff5a2f33fd

FWIW, XEmacs has used a bit of m4 magic to make --with-* and --enable-* equivalent for 15 years, and nobody has ever complained.  The autotools convention is a distinction without a difference, and confuses users when a program feature depends on an external library (especially where there are alternative implementations).

For 3.6 at least, there are still mentions of --with-optimizations in Doc/whatsnew/3.6.rst and README.

doc references fixed.  thanks!

remote: notified python-checkins@python.org of incoming changeset a5e2add2c37b
remote: notified python-checkins@python.org of incoming changeset 6ae0e6d435de
remote: notified python-checkins@python.org of incoming changeset ea9cc29a274b
remote: notified python-checkins@python.org of incoming changeset 38e9761ccc13

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.