Require Autoconf 2.71 or newer

[petk]

This updates the minimum required Autoconf version to 2.71.

• Autoconf versions 2.70 started supporting C11 standards.
• Autoconf 2.71 was released soon after 2.70 providing some bugfixes.

Changes:

• Removed obsolete AC_PROG_CC_C99 macro. In Autoconf 2.70 and later this is done by the AC_PROG_CC macro.
• m4_normalize is not needed for AC_CHECK_HEADERS and AC_CHECK_FUNCTIONS macros anymore, as the argument is normalized internally by Autoconf in these newer versions.
• Adjusted C11 check in configure.ac and added check also in phpize
  mode. Extensions using PHP headers should be also built with some
  C11-compliant compiler.
• Removed ac_cv_header_sys_types_h_makedev hack for AC_HEADER_MAJOR macro when using Autoconf versions prior to 2.70.
• Replaced AC_CONFIG_MACRO_DIR with preferred AC_CONFIG_MACRO_DIRS.

This also enables using --runstatedir configure option in the future.

Current known target systems with Autoconf versions <= 2.69:

• AIX (Autoconf 2.69)
• RHEL 8, RHEL 9, AlmaLinux 8, RockyLinux 8: Autoconf 2.69 (some has Autoconf 2.71provided as a separate package or EPEL repository).
• Solaris 10: Autoconf 2.69 via OpenCSW
• Solaris 11.4: Autoconf 2.69 (updated 2.71 available as of 11.4.81 update)

Autoconf versions can be also observed at:

• https://repology.org/project/autoconf/versions
• https://pkgs.org/search/?q=autoconf

[petk]

Updating it to 2.71 instead since 2.71 was released only one month after 2.70 and it includes some important bug fixes.

Edit: If anyone would like to review this, more than welcome. I've added for now only those that have changed build system files semi-recently...

[NattyNarwhal]

Seems to work fine on macOS/arm and linux/ppc64. Testing this PR on AIX (had to upgrade from 2.69...) and it seems OK so far, but builds are pretty slow on that system.

[petk]

had to upgrade from 2.69...

Yes, I'm now also worried how this might affect building extensions. When building PHP extension on a system where some old Autoconf is installed by default this will cause issues. For php-src it shouldn't be so much of a problem.

I can also wait with this update for another year or two or go with two separate versions (like it was once already done in the past). Requiring 2.71 for php-src and 2.68 for extensions (in that phpize.m4 file).

I'm also rechecking all systems and their Autoconf versions...

[petk]

Added here now also C11 check in phpize because when PHP extensions use PHP headers they should also be built with some C11-compliant compiler.

[TimWolla]

No strong feeling regarding my comment, I'm happy either way.

[iluuu1994]

No technical review, but I'm happy officially enforcing C11.

[petk]

I'm just adding a note here in case Autoconf 2.71 version will be too much for some system that we're unaware at this point. Instead of this PR, the following can be done to make the C11 check working when Autoconf 2.70+ is installed but skipped if Autoconf 2.69 or lower is installed:

--- a/configure.ac
+++ b/configure.ac
@@ -120,6 +120,10 @@ dnl ----------------------------------------------------------------------------
 
 PKG_PROG_PKG_CONFIG
 AC_PROG_CC([cc gcc])
+
+m4_version_prereq([2.70], [AS_CASE([$ac_prog_cc_stdc], [c99|c89|no],
+  [AC_MSG_ERROR([C compiler would not accept C11 code.])])])
+
 PHP_DETECT_ICC
 PHP_DETECT_SUNCC

However, with this, exactly those old problematic compilers are most likely used on a system, where Autoconf 2.69 is used so the user won't notice that C11 is needed then.

Edit: Or, if such case will pop up, this trick can be also used in phpize. For example: building and installing PHP with Autoconf 2.71+ but using "phpize" on the same system where default Autoconf is 2.69.

[bukka]

Isn't 2.69 still default on RHEL 8? If so or if it's still anywhere on any supported distro, then I'm -1 on this.

[remicollet]

Isn't 2.69 still default on RHEL 8? If so or if it's still anywhere on any supported distro, then I'm -1 on this.

• RHEL-8 has 2.69 (and CentOS, AlmaLinux, RockyLinux and other clones)
• RHEL-9 has 2.69
• RHEL-10 has 2.71
• Fedora has 2.72

So, I'm also -1

[remicollet]

Additional notes: EPEL-8 and EPEL-9 have an autoconf2.7x package providing autoconf/autoheader version 2.71

So, a workaround exists for users, but not for the distro itself

[TimWolla]

So, a workaround exists for users, but not for the distro itself

@remicollet Will RHEL 8/9 itself even provide PHP 8.6? I suspect no? In that case find it reasonable for users who want the latest and great PHP version to also install a newer autoconf from EPEL.

[petk]

Before I forget about it: Added here also AC_CONFIG_MACRO_DIR > AC_CONFIG_MACRO_DIRS change and rebased against current master branch which includes updated libtool files.

[petk]

I've added these mentioned legacy systems to the list in the PR for now to have a bit of an overview.

Overall, I think we need to be a bit more pragmatic here than just observe what is the default Autoconf version on some system. On these systems also other default versions of packages are outdated and building PHP there would require a lot of custom builds of dependencies already. And building PHP that is downloaded from php.net as a tar archive doesn't need Autoconf (configure script is there already generated). But the issue might occur when building extensions with pecl, pie or separately via phpize, which all require Autoconf installed.

Well, we can also wait with this for another year (or two). I wouldn't wait longer, for example, Solaris 11 EOL in year 2037 sounds like something unrealistic.

[iluuu1994]

@bukka @remicollet Given your comments and the response by @petk and @TimWolla, can you clarify whether you hard-object and would like to require an RFC for this?

[bukka]

I'd prefer to wait a bit longer for sure.

[remicollet]

I'd also prefer to wait a bit longer

[ericnorris]

The vote to include this in PHP 8.6 has passed: https://wiki.php.net/rfc/min_supported_versions_php_8_6.

[bukka]

Tim seems to be fine to postpone to 8.7 (basically master as soon as PHP-8.6 is branched) which makes a bit more sense to me as well (there is no advantage to merge it that late in cycle): https://externals.io/message/131975#132029

With regard to the timing, it was just convenient to bundle the two upgrades together and I relied on Eric to handle the RFC stuff. Given that it's cleanup-only and the first Alphas have already been released, I'd be okay with delaying the merge of the autoconf upgrade for (early) PHP 8.7.

[petk]

Coming back to this PR, the more I think about all the lacky reasons against merging this to PHP 8.6, the more I feel they are complete nonsense. But now I want to see PHP 8.6 build with Autoconf 2.69 in those old distros in custom non default repositories and all the compiler adjustment patches. 😄

[remicollet]

Will RHEL 8/9 itself even provide PHP 8.6?

I can't say, but still actively maintained, PHP 8.4 appeared in 10.2, and will also be in 9.9
Probably 8.5 or 8.6 will come later

To clarify autoconf 2.71 availability

RHEL-9 provides autoconf271 package in its official repository.

Can be used with (changing $PATH)

source /opt/rh/autoconf271/enable

Or

export PHP_AUTOCONF=/opt/rh/autoconf271/bin/autoconf
export PHP_AUTOHEADER=/opt/rh/autoconf271/bin/autoheader

RHEL-8 doesn't have it, but EPEL-8/EPEL-9 provides autoconf2.7x package.

Can be used with

export PHP_AUTOCONF=/usr/bin/autoconf27
export PHP_AUTOHEADER=/usr/bin/autoheader27

[TimWolla]

@remicollet Thank you for the clarification. I wasn't aware that RHEL 10 include more than one PHP version in the official repositories - and that new software is shipped for “oldstable” versions.

So RHEL 9 actually has autoconf 2.71 in the official repositories. Is this a recent change? From what I understand from your comment in March you said that autoconf 2.71 is only available in EPEL.

RHEL 8 is already out of the “Full Support” phase according to https://endoflife.date/rhel.

---

So including this in PHP 8.6 seems safe to me, RHEL 10 and RHEL 9 can theoretically get PHP 8.6 in a clean way (and RHEL 8 users really ought to upgrade). Requesting review from the PHP 8.6 RMs to make a decision here.

[remicollet]

@remicollet Thank you for the clarification. I wasn't aware that RHEL 10 include more than one PHP version in the official repositories - and that new software is shipped for “oldstable” versions.

Alternative versions exist since RHEL-6 (with Software Collections), and since RHEL-8 (with modules) and since RHEL-10 (with name prefix) so for 14 years ;)

So RHEL 9 actually has autoconf 2.71 in the official repositories. Is this a recent change?

Since 9.4 (2 years ago)

From what I understand from your comment in March you said that autoconf 2.71 is only available in EPEL.

I missed it ;)

RHEL 8 is already out of the “Full Support” phase according to https://endoflife.date/rhel.

But still maintained until 2033

So including this in PHP 8.6 seems safe to me, RHEL 10 and RHEL 9 can theoretically get PHP 8.6 in a clean way (and RHEL 8 users really ought to upgrade).

Some users are strange goal, wanting to keep their "old" distro, and use "new" software

From some stat from my repo, EL-8 = 24%, EL-9 = 63%, EL-10 = 13%

Requesting review from the PHP 8.6 RMs to make a decision here.

Indeed

[mbeccati]

Autoconf is needed when building from git, so it doesn't affect regular users of such distros.

It just makes it a bit more complicate for those tracking git, who will need to have a custom-built autoconf somewhere to generate the configure script. It's not some crazy exotic requirement. I had to do similar things in past when Ubuntu on my CI was too old and I still wanted daily builds of all PHP versions.

My 2c