From 527159aa63c63d8573e7074eb0a3e547f05c54b4 Mon Sep 17 00:00:00 2001 From: Piraty Date: Fri, 8 Mar 2024 17:30:24 +0100 Subject: [PATCH 1/2] autoconf-archive: add upstream patch to fix building with lto fixes building python3 with -flto checking whether float word ordering is bigendian... unknown --- ..._BIGENDIAN-Fix-bug-AX_C_FLOAT_WORDS_.patch | 138 ++++++++++++++++++ srcpkgs/autoconf-archive/template | 2 +- 2 files changed, 139 insertions(+), 1 deletion(-) create mode 100644 srcpkgs/autoconf-archive/patches/0001-AX_C_FLOAT_WORDS_BIGENDIAN-Fix-bug-AX_C_FLOAT_WORDS_.patch diff --git a/srcpkgs/autoconf-archive/patches/0001-AX_C_FLOAT_WORDS_BIGENDIAN-Fix-bug-AX_C_FLOAT_WORDS_.patch b/srcpkgs/autoconf-archive/patches/0001-AX_C_FLOAT_WORDS_BIGENDIAN-Fix-bug-AX_C_FLOAT_WORDS_.patch new file mode 100644 index 00000000000000..6f39caefaf5897 --- /dev/null +++ b/srcpkgs/autoconf-archive/patches/0001-AX_C_FLOAT_WORDS_BIGENDIAN-Fix-bug-AX_C_FLOAT_WORDS_.patch @@ -0,0 +1,138 @@ +From 23be7ccd7f306fbc73b3f33e2f5ead716d120eef Mon Sep 17 00:00:00 2001 +From: Dan Amelang +Date: Fri, 19 May 2023 14:13:37 -0700 +Subject: [PATCH] AX_C_FLOAT_WORDS_BIGENDIAN: Fix bug + "AX_C_FLOAT_WORDS_BIGENDIAN fails whenever interprocedural optimization is + enabled." + +Previous versions of this macro would not work when interprocedural +optimization (via link-time optimization) was enabled. This would happen +when, say, the GCC/clang "-flto" flag, or the ICC "-ipo" flag was used, for +example. The problem was that under these conditions, the compiler did not +allocate for and write the special float value in the data segment of the +test object file. Thus, the special value (in platform-dependent binary form) +could not be found, and the macro would fail. + +The solution to the above problem was to: + + 1) Compile and link a whole test program rather than just compile an + object file. + + 2) Add code that requires the compiler to write the special value to + the data segment of the program executable. + +For further details, refer to the documentation in the macro source file. Note +that this change already increments the serial number of the file. + +This change resolves the following issues: + +CPython issue #89640 + https://github.com/python/cpython/issues/89640 + +Gentoo bug #700012 + https://bugs.gentoo.org/700012 + +Cairo issue #459 + https://gitlab.freedesktop.org/cairo/cairo/-/issues/459 + +Poky (Yocto Project) #12699 + https://lists.yoctoproject.org/g/poky/topic/89131836 +--- + m4/ax_c_float_words_bigendian.m4 | 61 ++++++++++++++++++++++++++++---- + 1 file changed, 55 insertions(+), 6 deletions(-) + +diff --git a/m4/ax_c_float_words_bigendian.m4 b/m4/ax_c_float_words_bigendian.m4 +index 216b90d..5203684 100644 +--- a/m4/ax_c_float_words_bigendian.m4 ++++ b/m4/ax_c_float_words_bigendian.m4 +@@ -27,32 +27,81 @@ + # If neither value is found, the user is instructed to specify the + # ordering. + # ++# Early versions of this macro (i.e., before serial 12) would not work ++# when interprocedural optimization (via link-time optimization) was ++# enabled. This would happen when, say, the GCC/clang "-flto" flag, or the ++# ICC "-ipo" flag was used, for example. The problem was that under ++# these conditions, the compiler did not allocate for and write the special ++# float value in the data segment of the object file, since doing so might ++# not prove optimal once more context was available. Thus, the special value ++# (in platform-dependent binary form) could not be found in the object file, ++# and the macro would fail. ++# ++# The solution to the above problem was to: ++# ++# 1) Compile and link a whole test program rather than just compile an ++# object file. This ensures that we reach the point where even an ++# interprocedural optimizing compiler writes values to the data segment. ++# ++# 2) Add code that requires the compiler to write the special value to ++# the data segment, as opposed to "optimizing away" the variable's ++# allocation. This could be done via compiler keywords or options, but ++# it's tricky to make this work for all versions of all compilers with ++# all optimization settings. The chosen solution was to make the exit ++# code of the test program depend on the storing of the special value ++# in memory (in the data segment). Because the exit code can be ++# verified, any compiler that aspires to be correct will produce a ++# program binary that contains the value, which the macro can then find. ++# ++# How does the exit code depend on the special value residing in memory? ++# Memory, unlike variables and registers, can be addressed indirectly at run ++# time. The exit code of this test program is a result of indirectly reading ++# and writing to the memory region where the special value is supposed to ++# reside. The actual memory addresses used and the values to be written are ++# derived from the the program input ("argv") and are therefore not known at ++# compile or link time. The compiler has no choice but to defer the ++# computation to run time, and to prepare by allocating and populating the ++# data segment with the special value. For further details, refer to the ++# source code of the test program. ++# ++# Note that the test program is never meant to be run. It only exists to host ++# a double float value in a given platform's binary format. Thus, error ++# handling is not included. ++# + # LICENSE + # +-# Copyright (c) 2008 Daniel Amelang ++# Copyright (c) 2008, 2023 Daniel Amelang + # + # Copying and distribution of this file, with or without modification, are + # permitted in any medium without royalty provided the copyright notice + # and this notice are preserved. This file is offered as-is, without any + # warranty. + +-#serial 11 ++#serial 12 + + AC_DEFUN([AX_C_FLOAT_WORDS_BIGENDIAN], + [AC_CACHE_CHECK(whether float word ordering is bigendian, + ax_cv_c_float_words_bigendian, [ + + ax_cv_c_float_words_bigendian=unknown +-AC_COMPILE_IFELSE([AC_LANG_SOURCE([[ ++AC_LINK_IFELSE([AC_LANG_SOURCE([[ + +-double d = 90904234967036810337470478905505011476211692735615632014797120844053488865816695273723469097858056257517020191247487429516932130503560650002327564517570778480236724525140520121371739201496540132640109977779420565776568942592.0; ++#include ++ ++static double m[] = {9.090423496703681e+223, 0.0}; ++ ++int main (int argc, char *argv[]) ++{ ++ m[atoi (argv[1])] += atof (argv[2]); ++ return m[atoi (argv[3])] > 0.0; ++} + + ]])], [ + +-if grep noonsees conftest.$ac_objext >/dev/null ; then ++if grep noonsees conftest$EXEEXT >/dev/null ; then + ax_cv_c_float_words_bigendian=yes + fi +-if grep seesnoon conftest.$ac_objext >/dev/null ; then ++if grep seesnoon conftest$EXEEXT >/dev/null ; then + if test "$ax_cv_c_float_words_bigendian" = unknown; then + ax_cv_c_float_words_bigendian=no + else +-- +2.44.0 + diff --git a/srcpkgs/autoconf-archive/template b/srcpkgs/autoconf-archive/template index 7229da59a8e7e2..68a71b00a4d83e 100644 --- a/srcpkgs/autoconf-archive/template +++ b/srcpkgs/autoconf-archive/template @@ -1,7 +1,7 @@ # Template file for 'autoconf-archive' pkgname=autoconf-archive version=2023.02.20 -revision=1 +revision=2 build_style=gnu-configure hostmakedepends="texinfo" depends="autoconf" From 52d032413130a40a6f5292b0355022df0d210111 Mon Sep 17 00:00:00 2001 From: Piraty Date: Fri, 8 Mar 2024 17:32:55 +0100 Subject: [PATCH 2/2] python3: use patched autoconf-archive to fix lto build no revbump as Void's default build configuration is not affected --- srcpkgs/python3/template | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/srcpkgs/python3/template b/srcpkgs/python3/template index d3342dda925a8c..48bcc646077ed2 100644 --- a/srcpkgs/python3/template +++ b/srcpkgs/python3/template @@ -11,7 +11,7 @@ configure_args="--enable-shared --enable-ipv6 --enable-optimizations --with-dbmliborder=gdbm:ndbm --with-system-expat --with-system-ffi --without-ensurepip ac_cv_working_tzset=yes" pycompile_dirs="usr/lib/python${version%.*}" -hostmakedepends="pkgconf" +hostmakedepends="pkgconf autoconf-archive automake" makedepends="libffi-devel readline-devel gdbm-devel openssl-devel expat-devel sqlite-devel bzip2-devel zlib-devel liblzma-devel" depends="ca-certificates" @@ -64,6 +64,11 @@ post_patch() { fi } +# https://github.com/python/cpython/issues/89640 +pre_configure() { + autoreconf -vfi +} + do_configure() { # If these are set, distutils will default to cc and attempt to pass # `-R` to the compiler for every compiled extension that sets an