This code does not appear to be used anywhere in the python code base.
The use was removed in eb81795d7d.
(cherry picked from commit b91a3a0d61)
Co-authored-by: Eitan Adler <grimreaper@users.noreply.github.com>
Add -g to LDFLAGS when compiling with LTO to get debug symbols.
(cherry picked from commit 06fe77a84b)
Co-authored-by: Victor Stinner <vstinner@redhat.com>
Setup modules are no longer built with -DPy_BUILD_CORE by default,
as using that flag may now require including additional internal-only header files.
Instead, only the modules that specifically need it use that setting.
(cherry picked from commit 063db62aab)
Co-authored-by: xdegaye <xdegaye@gmail.com>
To support reproducible builds, the setting of of SOURCE_DATE_EPOCH triggers the py_compile module -- and by extension, compileall -- to forcibly compile with hash-based .pyc files. This eliminates the possibility of timestamp-based .pyc files which vary between builds.
glibc is deprecating libcrypt in favor of libxcrypt, however python assumes
that crypt.h will always be included. This change makes the header inclusion
explicit when libxcrypt is present on the system.
Add https://www.gnu.org/software/autoconf-archive/ax_check_openssl.html
to auto-detect compiler flags, linker flags and libraries to compile
OpenSSL extensions. The M4 macro uses pkg-config and falls back to
manual detection.
Add autoconf magic to detect usable X509_VERIFY_PARAM_set1_host()
and related functions.
Refactor setup.py to use new config vars to compile _ssl and _hashlib
modules.
Signed-off-by: Christian Heimes <christian@python.org>
When a single .c file contains several functions and/or methods with
the same name, a safety _METHODDEF #define statement is generated
only for one of them.
This fixes the bug by using the full name of the function to avoid
duplicates rather than just the name.
* bpo-28643: Record profile-opt build progress with stamp files
The profile-opt makefile target is expensive to build. Since the
makefile does not contain complete dependency information for this
target, much extra work can get done if the build is interrupted and
re-started. Even running "make" a second time will result in a huge
amount of redundant work.
As a minimal fix (rather than removing recursive "make" and adding a
proper dependency graph), split the profile-opt target into parts:
- ensure tree is clean (profile-clean-stamp)
- build with profile generation enabled (profile-gen-stamp)
- run task to generate profile information (profile-run-stamp)
- build optimized Python using above information (profile-opt)
We use "stamp" files to record completion of the steps. Running
"make clean" will not remove the profile-run-stamp file.
Other minor changes:
- remove the "build_all_use_profile" target. I don't expect callers
of the makefile to use this target so that should be safe.
- remove execution of "profile-removal" at end of "profile-opt". I
don't see any reason to not to keep the profile information, given
the cost to generate it. Removing the "profile-run-stamp" file
will force re-generation of it.
Fix the logic in python-config.sh to avoid attempting to substitute
prefix in a variable that might have already been subject to
substitution. This e.g. happened if @exec_prefix@ was defined as
"${prefix}" (which is the default of the configure script) -- in which
case the exec_prefix_build variable was initialized with
already-subtituted prefix, and then another round of substitution was
performed which might have resulted in duplicate prefix.
To avoid that, rename the variables so that the variables matching
likely configure names (prefix, exec_prefix) retain their original
values and a '_real' suffix is used for the real values of prefix.
Furthermore, replace the unnecessary prefix and exec_prefix
substitutions with direct prefix_real references since the sed
always replaced the whole string anyway by design.
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.
