This patch syncs and bumps the minimum required version of Autoconf for
the `phpize.m4` script and the main `configure.ac` from previously mixed
2.64 and 2.59 to 2.68.
At the time of this writing Autoconf 2.63 is still the version on
Centos 6, however by the PHP 7.3 release current systems out there
should all have pretty much updated Autoconf versions to 2.64+ at
least. Centos 7 already has Autoconf 2.69, for example.
This provides more options to update and get current with the *nix
build system and also avoids broken builds in certain cases as pointed
out in the relevant discussion [1].
Additionally, phpize also already provides the `AX_CHECK_COMPILE_FLAG`
Autoconf Archive m4 file that has Autoconf 2.64 minimum requirement.
Autoconf 2.68 was released in 2010, 8 years ago, relative to this patch.
[1] https://github.com/php/php-src/pull/3562
We work around a strlen() optimization bug in GCC 8[1] by checking
whether the used GCC exhibits the broken behavior, and if so by
disabling `optimize-strlen`.
[1] <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86914>
Autoconf 2.50 released in 2001 made several macros obsolete including
the AC_TRY_RUN, AC_TRY_COMPILE and AC_TRY_LINK:
http://git.savannah.gnu.org/cgit/autoconf.git/tree/ChangeLog.2
These macros should be replaced with the current AC_FOO_IFELSE instead:
- AC_TRY_RUN with AC_RUN_IFELSE and AC_LANG_SOURCE
- AC_TRY_LINK with AC_LINK_IFELSE and AC_LANG_PROGRAM
- AC_TRY_COMPILE with AC_COMPILE_IFELSE and AC_LANG_PROGRAM
PHP 5.4 to 7.1 require Autoconf 2.59+ version, PHP 7.2 and above require
2.64+ version, and the PHP 7.2 phpize script requires 2.59+ version which
are all greater than above mentioned 2.50 version therefore systems
should be well supported by now.
This patch was created with the help of autoupdate script:
autoupdate <file>
Reference docs:
- https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/Obsolete-Macros.html
- https://www.gnu.org/software/autoconf/manual/autoconf-2.59/autoconf.pdf
Autoconf 2.50 made several changes to macro calls. These include also
arguments passed to AC_OUTPUT macro. The upgrading chapter in Autoconf
documentation include an example of using AC_OUTPUT with
AC_CONFIG_FILES and AC_CONFIG_COMMANDS:
- https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/Obsolete-Macros.html
PHP 5.4 to 7.1 require Autoconf 2.59+, PHP 7.2+ require Autoconf 2.64+,
and PHP 7.2 phpize script requires Autoconf 2.59+ which are all greater
than above mentioned 2.50 version. Systems out there should well support
this by now.
This patch was created with the help of autoupdate script:
autoupdate <file>
More info on where exactly this got deprecated:
- ftp://ftp.gnu.org/old-gnu/Manuals/autoconf-2.13/html_mono/autoconf.html
- ftp://ftp.auckland.ac.nz/pub/gnu/Manuals/autoconf-2.52/html_chapter/autoconf_15.html
- http://git.savannah.gnu.org/cgit/autoconf.git/tree/NEWS
Autoconf 2.50 released in 2001 has made several macros obsolete. Instead
of the AC_STRUCT_ST_BLKSIZE and AC_STRUCT_ST_RDEV the new
AC_CHECK_MEMBERS should be used.
When checking for the presence of stat struct members st_blkzize and
st_rdev the new AC_CHECK_MEMBERS macro defines new constants
HAVE_STRUCT_STAT_ST_BLKSIZE and HAVE_STRUCT_STAT_ST_RDEV.
Old constants HAVE_ST_BLKSIZE and HAVE_ST_RDEV need to be replaced
respectively in PHP code (this patch) and in PHP extenstions if they use
them.
PHP 5.4 to 7.1 require Autoconf 2.59+ version, PHP 7.2 and above require
2.64+ version, and the PHP 7.2 phpize script requires 2.59+ version which
are all greater than above mentioned 2.50 version.
Some editors utilizing .editorconfig automatically trim whitespaces. For
convenience this patch removes whitespaces in certain build files:
- ext/*/config*.m4
- configure.ac
- acinclude.m4
The $Id$ keywords were used in Subversion where they can be substituted
with filename, last revision number change, last changed date, and last
user who changed it.
In Git this functionality is different and can be done with Git attribute
ident. These need to be defined manually for each file in the
.gitattributes file and are afterwards replaced with 40-character
hexadecimal blob object name which is based only on the particular file
contents.
This patch simplifies handling of $Id$ keywords by removing them since
they are not used anymore.
Since PHP 7.2 the minimum autoconf version is 2.64. The configure.ac
script file includes also AX_CHECK_COMPILE_FLAG macro call so besides
only checking it in buildconf script this bumps the autoconf here too.
The phpize.m4 script is for now still relaxed to 2.59 version since some
still supported systems such as CentOS 6 still include autoconf 2.63
version and might require calling phpize on some old extensions.
Autoconf doesn't mention the AC_CONFIG_HEADER macro since the v2.13
released in 1999 anywhere in the documentation. Future of this macro is
unclear and commented as possible candidate for obsoletion in the
autoconf source code. Since it is just a wrapper around the main
AC_CONFIG_HEADERS macro, the functionality is the same, and also more
clear to find it in the autoconf documentation and avoid possible future
obsoletion.
On systems without glibc, such as Alpine with Musl libc, the function attributes
are not supported. GCC 6 doesn't properly omit some systems. This is
already fixed in GCC 7 but for systems with GCC 6 and ones without
glibc, this additional check fixes this bug.
The configure script already warns users at the beginning with
unrecognized options warning so additional check is not required. These
sapis were also removed from the PHP core.
Usage of VLA is not portable, wile supported by some compilers. For
instance, GCC supports it even if -std=c89 is passed. Even if we would
switch to C99, it would be still not portable at least with VC++. Thus,
adding a centralized check so such code can be guarded and moved to
alloca() if needed.
As described in bug report #75722, the configure script (acinclude.m4)
currently searches for the valgrind header file and enables valgrind
support if found.
When cross-compiling the searched paths are invalid for the target
platform because they belong to the host system. At the moment, there is
no way to tell the build system a dedicated path where to look for the
header file.
This leads to the issue, that when cross-compiling eg. for ARMv5 platform,
that valgrind header file is detected - e.g. because host system is amd64 -
and support is enabled - but target platform will never support valgrind
(valgrind requires e.g. at least ARMv7).
This change reworks the detection so that user could manually opt-in
valgrind support and optionally specify a directory where the build system
should look for the header file using the --with-valgrind option.
Christoph M. Becker