delta/cpython-git.git/configure.ac, branch 3.6

bpo-34602: Avoid failures setting macOS stack resource limit (GH-14546) (GH-14549)

2019-07-02T07:48:59+00:00

Under some conditions the earlier fix for bpo-18075, "Infinite recursion
tests triggering a segfault on Mac OS X", now causes failures on macOS
when attempting to change stack limit with resource.setrlimit
resource.RLIMIT_STACK, like regrtest does when running the test suite.
The reverted change had specified a non-default stack size when linking
the python executable on macOS.  As of macOS 10.14.4, the previous
code causes a hard failure when running tests, although similar
failures had been seen under some conditions under some earlier
systems.  Reverting the change to the interpreter stack size at link
time helped for release builds but caused some tests to fail when
built --with-pydebug.  Try the opposite approach: continue to build
the interpreter with an increased stack size on macOS and remove
the failing setrlimit call in regrtest initialization.  This will
definitely avoid the resource.RLIMIT_STACK error and should have
no, or fewer, side effects.
(cherry picked from commit 5bbbc733e6cc0804f19b071944af8d4719e26ae6)

Co-authored-by: Ned Deily

bpo-34602: Avoid failures setting macOS stack resource limit (GH-13011) (GH-13014)

2019-04-29T19:56:58+00:00

Under some conditions the earlier fix for bpo-18075, "Infinite recursion
tests triggering a segfault on Mac OS X", now causes failures on macOS
when attempting to change stack limit with resource.setrlimit
resource.RLIMIT_STACK, like regrtest does when running the test suite.
The reverted change had specified a non-default stack size when linking
the python executable on macOS.  As of macOS 10.14.4, the previous
code causes a hard failure when running tests, although similar
failures had been seen under some conditions under some earlier
systems.  For now, revert the original change and resume using
the default stack size when linking the interpreter.
(cherry picked from commit 883dfc668f9730b00928730035b5dbd24b9da2a0)

Co-authored-by: Ned Deily

[3.6] bpo-35257: Avoid leaking LTO linker flags into distutils (GH-10900) (GH-11265)

2018-12-20T20:31:22+00:00

When compiling 3rd party C extensions, the linker flags used by the
compiler for the interpreter and the stdlib modules, will get
leaked into distutils. In order to avoid that, the PY_CORE_LDFLAGS
and PY_LDFLAGS_NODIST are introduced to keep those flags separated.

(cherry picked from commit cf10a750f4b50b6775719cfb17bee00bc3a9c60b)

bpo-35351: Pass link time optimization flags to CFLAGS_NODIST (GH-10797)

2018-12-09T08:35:13+00:00

When using link time optimizations, the -flto flag is passed to
BASECFLAGS, which makes it propagate to distutils. Those flags
should be reserved for the interpreter and the stdlib extension
modules only, thus moving those flags to CFLAGS_NODIST.
(cherry picked from commit f92c7aa1ae81efa475b5aecf66e4711ef0f52c4c)

Co-authored-by: stratakis

bpo-28015: Support LTO build with clang (GH-9908) (GH-10922)

2018-12-09T08:08:43+00:00

.o generated by clang in LTO mode actually are LLVM bitcode files, which
leads to a few errors during configure/build step:

- add lto flags to the BASECFLAGS instead of CFLAGS, as CFLAGS are used
  to build autoconf test case, and some are not compatible with clang LTO
  (they assume binary in the .o, not bitcode)
- force llvm-ar instead of ar, as ar is not aware of .o files generated
  by clang -flto
(cherry picked from commit 5ad36f9b21a3aa3b2265b1b43d73522cc3322df2)

Co-authored-by: serge-sans-paille

[3.6] bpo-31625: Stop using ranlib (GH-10417)

2018-11-29T14:43:24+00:00

* stop using ranlib (closes bpo-31625) (#3815)

Instead, simply pass 's' to ar.

* explicitly list objects for the ar command (#3824)

$^ is not portable.

closes bpo-31625

[3.6] bpo-35214: Initial clang MemorySanitizer support (GH-10479) (GH-10493)

2018-11-13T00:10:21+00:00

Adds configure flags for msan and ubsan builds to make it easier to enable.
These also encode the detail that address sanitizer and memory sanitizer
should disable pymalloc.

Define MEMORY_SANITIZER when appropriate at build time and adds workarounds
to existing code to mark things as initialized where the sanitizer is otherwise unable to
determine that.  This lets our build succeed under the memory sanitizer.  not all tests
pass without sanitizer failures yet but we're in pretty good shape after this.

(cherry picked from commit 1584a0081500d35dc93ff88e5836df35faf3e3e2)

Contributed by Gregory P. Smith [Google LLC]

Also includes a whitespace fix from make patchcheck to _posixsubprocess.c - unrelated to the main change that makes the CI happy so I'm just doing it now rather than creating a separate PR.

[3.6] bpo-31354: Let configure --with-lto work on all builds (GH-10261)

2018-11-07T22:05:13+00:00

Allow configure --with-lto to apply to all builds, not just profile-opt builds.

Whether this is actually useful or not must be determined by the person
building CPython using their own toolchain.

My own quick test on x86_64 Debian 9 (gcc 6.3, binutils 2.28) seemed
to suggest that it wasn't, but I expect better toolchains can or will exist
at some point.  The point is to allow it at all.

Don't run AC_STRUCT_TIMEZONE twice. (GH-9305)

2018-09-14T16:28:31+00:00

(cherry picked from commit a4414ef20b971e6803309acebfa85b1621ac625e)

Co-authored-by: Benjamin Peterson

[3.6] bpo-34652: Remove lchmod from the big func checking block. (GH-9250)

2018-09-13T00:37:46+00:00

A fix for 883702ebb8bbfa749ef0040d1b58d6222bf589ee..
(cherry picked from commit ed709d5699716bf7237856dc20aba321e2dfff6d)