PHP won't compile due to C++17

davidc

Verified User
Joined
Jun 19, 2020
Messages
85
For the last 3 days (and today), PHP has failed to update from 8.2.18 to 8.2.19 and also from 8.3.6 to 8.3.7.

The error is: configure: error: *** A compiler with support for C++17 language features is required.

Looking at the CustomBuild log, reveals:

Rich (BB code):
Updating PHP 8.3
....
checking whether to enable internationalization support... yes
checking whether to enable internationalization support... yes
checking for icu-uc >= 50.1 icu-io icu-i18n... yes
checking for g++... g++
checking whether the compiler supports GNU C++... yes
checking whether g++ accepts -g... yes
checking for g++ option to enable C++11 features... -std=gnu++11
checking how to run the C++ preprocessor... g++ -std=gnu++11 -E
checking if intl requires -std=gnu++17... yes
checking whether g++ -std=gnu++11 supports C++17 features with -std=c++17... no
checking whether g++ -std=gnu++11 supports C++17 features with +std=c++17... no
checking whether g++ -std=gnu++11 supports C++17 features with -h std=c++17... no
checking whether g++ -std=gnu++11 supports C++17 features with -std=c++1z... no
checking whether g++ -std=gnu++11 supports C++17 features with +std=c++1z... no
checking whether g++ -std=gnu++11 supports C++17 features with -h std=c++1z... no
configure: error: *** A compiler with support for C++17 language features is required.
install_php: failed to compile '/usr/local/directadmin/custombuild/cache/php-8.2.19.tar.gz' inside '/usr/local/directadmin/custombuild/tmp/tmp.pJnkRrTHDn.php-8.2.19.tar.gz'
Updating PHP 8.3
....
checking whether to enable internationalization support... yes
checking for icu-uc >= 50.1 icu-io icu-i18n... yes
checking for g++... g++
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking how to run the C++ preprocessor... g++ -E
checking if intl requires -std=gnu++17... yes
checking whether g++ supports C++17 features with -std=c++17... no
checking whether g++ supports C++17 features with +std=c++17... no
checking whether g++ supports C++17 features with -h std=c++17... no
checking whether g++ supports C++17 features with -std=c++1z... no
checking whether g++ supports C++17 features with +std=c++1z... no
checking whether g++ supports C++17 features with -h std=c++1z... no
configure: error: *** A compiler with support for C++17 language features is required.
install_php: failed to compile '/usr/local/directadmin/custombuild/cache/php-8.3.7.tar.gz' inside '/usr/local/directadmin/custombuild/tmp/tmp.UUcqws5HY2.php-8.3.7.tar.gz'

Looking for a solution, I discovered this link - Fix check for newer versions of ICU

I think the bottom line is this response referring to buildconf -f before ./configure

Is this something that CustomBuild can/will deal with or must I make the manual corrections?

David
 
Have to tried updating gcc?
No.

And, how do you do this?

Code:
yum install gcc-c++

I wanted to hear from DirectAdmin if there is a provision to upgrade the compiler. I guess not, as the compiler appears to be 9 years old.

Code:
# g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.8.5/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style=gnu --enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin --enable-initfini-array --disable-libgcj --with-isl=/builddir/build/BUILD/gcc-4.8.5-20150702/obj-x86_64-redhat-linux/isl-install --with-cloog=/builddir/build/BUILD/gcc-4.8.5-20150702/obj-x86_64-redhat-linux/cloog-install --enable-gnu-indirect-function --with-tune=generic --with-arch_32=x86-64 --build=x86_64-redhat-linux
Thread model: posix
gcc version 4.8.5 20150623 (Red Hat 4.8.5-44) (GCC)

It may be time to pass this to the VPS hosting company's support.
 
I guess not, as the compiler appears to be 9 years old.
Well that's what you get from running an ancient long time EOL OS. Then OS parts tend to get ancient too.

DA does not support loose upgrading of OS parts. Maybe there is a way to compile G++ manually but I wouldn't recommend it as things like that can always cause odd issue on your system due to dependecencies.

Your VPS hosting company's support will almost certainly advise you to make backups, take a new vps (or clean this one and install) with new OS and then restore again.

Edit: Sorry, I interpreted the version wrongly.
 
Last edited:
This only affects CentOS 7 (that I'm aware of, perhaps it affects other older distributions?).

If you are running AlmaLinux 8 (and presumably AlmaLinux 9, although I haven't tested) then you don't run into this issue.

To patch this for CentOS 7 you will have to apply the changes to the state .m4 files (ext/intl/config.m4 and ext/intl/config.m4) and then rebuild the configure script with ./buildconf -f

Then the configure line will work.

I've attached the necessary patch files that need to be applied. One for PHP 8.2 and one for PHP 8.3.

After applying these patches files you will have to rebuild the configure script with ./buildconf -f and then your configure line will work.

Presumably... this will all be fixed by PHP in the next PHP release (i.e. PHP 8.2.20 and PHP 8.3.8) but can't be certain of that.

Of note, CentOS 7 reaches end of life at the end of June 2024, so a little over a month from now.

(I will also add that I don't know how to apply all of this within the realm of DirectAdmin's Custombuild system for compiling PHP. These are just instructions for blanket PHP compiling. Will DirectAdmin's developers want to apply this patch to their CustomBuild version of PHP? Or will they just want to skip this version of PHP 8.2 and PHP 8.3?)
 

Attachments

Look which RH version.
Code:
# g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.8.5/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style=gnu --enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin --enable-initfini-array --disable-libgcj --with-isl=/builddir/build/BUILD/gcc-4.8.5-20150702/obj-x86_64-redhat-linux/isl-install --with-cloog=/builddir/build/BUILD/gcc-4.8.5-20150702/obj-x86_64-redhat-linux/cloog-install --enable-gnu-indirect-function --with-tune=generic --with-arch_32=x86-64 --build=x86_64-redhat-linux
Thread model: posix
gcc version 4.8.5 20150623 (Red Hat 4.8.5-44) (GCC)
Are you meaning to imply that the OP is using Red Hat 4.8? That's not what that means.

That's just saying that the version of gcc is 4.8 on the OP's OS. I can't say for sure what OS the OP is using, but I get the exact same thing on my CentOS 7 servers. And CentOS 7 is very much still in life (albeit, only for about another month or so).

So, I'm not going to drag the OP for using an end-of-life OS.

Had this happened in July 2024, then we could probably say that the OP is using and end-of-life OS and would need to upgrade. Although... truth be told, while technically true, it would probably be in rather poor taste. I will still have CentOS 7 servers running in July. Do I know that they need to be upgraded? Yes. Can I do that by a snap of the fingers? No. Should I have maybe planned more accordingly? Yes. But generally speaking, you don't cut something off the moment it goes end-of-life.

Chances are all of this gets fixed in the next versions of PHP 8.2 and PHP 8.3 anyway, so all of this discussion is likely moot.

BUT... if it does not... then DirectAdmin will have a decision to make. Do they institute these patches for CentOS 7 systems? Or do they refuse to apply the patches and belittle all CentOS 7 DirectAdmin license holders to upgrade to a supported OS? That will be a fun soap opera to watch.
 
An update.

Yesterday, during the daily run of da build cron_execute, both PHP 8.2 and 8.3 updated fine. I did not have to do anything. I also do not know what was different, other than one line: download_cached: using cached '/usr/local/directadmin/custombuild/cache/php-8.2.19.tar.gz' file

The OP issue was due to checks in the PHP build script that weren't entirely correct, per the discussion here

quoting sparek:
Had this happened in July 2024, then we could probably say that the OP is using and end-of-life OS and would need to upgrade. Although... truth be told, while technically true, it would probably be in rather poor taste. I will still have CentOS 7 servers running in July. Do I know that they need to be upgraded? Yes. Can I do that by a snap of the fingers? No. Should I have maybe planned more accordingly? Yes. But generally speaking, you don't cut something off the moment it goes end-of-life.
I must agree with all of this. The most likely response from forums like this is, "Centos 7 is EOL in June ... you'd better upgrade...". I am sooo aware of this, yet a system OS upgrade takes planning and I won't desperately jump into an upgrade!

I posed this issue to my hosting company and the reply was expectedly, though disappointingly, "... more things are going to be breaking. ... upgrade to Alma Linux 8". This is a poor "support" mantra.

Centos 7 is NOT going to die (quit working) on June 30th.

Thank you Richard and sparek for your thoughtful comments and suggestions.

David
 
Centos 7 is NOT going to die (quit working) on June 30th.
That's correct, and also not fastly after that. You can keep using it until real security flaws or real issues might occur.
I don't know where you have servers, but at this moment Hetzner has some really interesting for cheap in the Auction which might be interesting.

But indeed take your time in considerations.
 
I'd be curious to know what version of DirectAdmin you are using.

As far as I know, DirectAdmin hasn't released PHP 8.2.19 or PHP 8.3.7 yet. At least according to the changelogs


Doesn't mention any PHP upgrades. Neither does the changelog for 1.664


But there's been several hotfixes for 1.663, maybe one of those bumped up the PHP version and the changelog didn't get updated (always a possibility).

And since 1.664 is in beta or whatever DirectAdmin calls their testing branch, I suppose it's possible the PHP upgrades are in that version and just not in the changelog.

I've yet to upgrade any of my DirectAdmin servers to 1.663 (which would also mean I haven't updated them to 1.664) so I don't really know what all is available in that release.
 
Back
Top