-std=c++03 is simply too old - we have 2017 and way newer standards and i doubt PHP upstream developers can and should forever care about 15 years or older compilers - there was a simliar bugreport some months ago with a ages old GCC

and while you say "I don't believe this is a duplicate of Bug #74265" did you read the comments?

[2017-05-03 05:23 UTC] rasmus@php.net
gcc version 4.1.2 ?? That compiler is over 10 years old. You are probably going to need to add -std=c99 to your build flags to get it to work on any modern codebase, or for heaven's sake, upgrade to a compiler from this decade.

Yes, I did read the comments on that bug, and a patch that worked was committed, and is present in 7.1.7. Yet, we get a similar message. It's fundamentally a different issue, since this is C++, not C.

As for the compiler, I'll upgrade from Solaris Studio 12.5 to 12.6, and see if that resolves the issue.

Upgrading to Solaris Studio 12.6 did not resolve the issue.

Unfortunately, C++ 03 (-std=sun03) is the default still for Solaris Studio, so as a sysadmin, I have no choice but to roll with it. How do we sucessfully force the compiler to C++ 14? When I try just using the switch "-std=c++14", the compiler throws errors like this:

"/opt/developerstudio12.6/lib/compilers/CC-gcc/include/c++/5.4.0/bits/basic_string.h", line 5300: Error: Could not find a match for __gnu_cxx::__to_xstring<_String, _CharT>(extern "C" int(*)(char*,unsigned long,const char*,__va_list_element*), unsigned long, const char[3], int) needed in std::to_string(int).
"/opt/developerstudio12.6/lib/compilers/CC-gcc/include/c++/5.4.0/ext/string_conversions.h", line 83: Note: Candidate 'std::string  __gnu_cxx::__to_xstring<std::string, char>(int(*)(char*,unsigned long,const char*,__va_list_tag*), unsigned long, const char*, ...)' is not viable: argument '__convf' can't be converted from 'extern "C" int(*)(char*,unsigned long,const char*,__va_list_element*)' to 'int(*)(char*,unsigned long,const char*,__va_list_tag*)'.

I'm going to continue working towards a resolution as well, but the fix is elusive currently.

well, use a state-of-the-art operating system or if you want to stick with outdated environments just use outdated PHP - as always you have to make decisions

currently PHP 5.6 works, 7.0.x has active support and so you hav etime to make your decisions

Supporting a diversity of platforms, like Windows, Linux, Solaris, and other Unix variants is actually a strength. I'm not going to argue with you any further about choice of platforms/compilers, because it's simply not helpful to the PHP community at-large.

In short, if you don't care about using Solaris, you (personally) don't have to. Please just go away, and let others provide *constructive* input that helps PHP continue to be an awesome cross-platform development tool.

@john, please check the latest dev branches with C++11 and up. A fix was pushed.

Thanks.

No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Re-Opened". Thank you.

Sorry, I did see the comment from 2018-07-09. I downloaded the development branch, and attempted compiling again.

Using the development 7.1 branch, I didn't experience the same error that was originally reported. But unfortunately, I ran into numerous other ext/intl compile errors dealing with C++, and could not get past the compile problems.

Thanks!  Re-opening.

Which exact errors came up? If the originally reported error is fixed, those new should be reported in a new ticket.

Thanks.

If you think this ticket should be closed, and a new one opened, we can do that. But even though the original error is not occurring now, it still fails to compile at the same point in compilation, ext/intl/intl_convertcpp.lo, whether using either C++11 or C++14. I'm definitely  open to suggestions on how best to handle this, whether in this ticket, or in a new one.

The class it is referencing (__gnu_cxx::__to_xstring) seems to be related to G++, so I probably don't have the proper CXXFLAGS, but I don't know what they should be, besides CXXFLAGS="-m64 -std=c++11".

Here is the new error:

/bin/sh /home/user/php-src/libtool --silent --preserve-dup-deps --mode=compile CC -I/usr/include  -Wno-write-strings -D__STDC_LIMIT_MACROS -DZEND_ENABLE_STATIC_TSRMLS_CACHE=1   -DU_USING_ICU_NAMESPACE=1 -Iext/intl/ -I/home/user/php-src/ext/intl/ -DPHP_ATOM_INC -I/home/user/php-src/include -I/home/user/php-src/main -I/home/user/php-src -I/home/user/php-src/ext/date/lib -I/usr/include/libxml2 -I/usr/local/include -I/home/user/php-src/TSRM -I/home/user/php-src/Zend  -m64 -D_POSIX_PTHREAD_SEMANTICS  -m64 -std=c++11  -c /home/user/php-src/ext/intl/intl_convertcpp.cpp -o ext/intl/intl_convertcpp.lo
"/opt/developerstudio12.6/lib/compilers/CC-gcc/include/c++/5.4.0/cstddef", line 51: Error: max_align_t is not defined.
"/opt/developerstudio12.6/lib/compilers/CC-gcc/include/c++/5.4.0/bits/basic_string.h", line 5300: Error: Could not find a match for __gnu_cxx::__to_xstring<_String, _CharT>(extern "C" int(*)(char*,unsigned long,const char*,__va_list_element*), unsigned long, const char[3], int) needed in std::to_string(int).
"/opt/developerstudio12.6/lib/compilers/CC-gcc/include/c++/5.4.0/ext/string_conversions.h", line 83: Note: Candidate 'std::string  __gnu_cxx::__to_xstring<std::string, char>(int(*)(char*,unsigned long,const char*,__va_list_tag*), unsigned long, const char*, ...)' is not viable: argument '__convf' can't be converted from 'extern "C" int(*)(char*,unsigned long,const char*,__va_list_element*)' to 'int(*)(char*,unsigned long,const char*,__va_list_tag*)'.
...
<redacted, repeated errors>
...
"/usr/include/sys/va_impl.h", line 101: Error: Only one of a set of overloaded functions can be extern "C".
"/home/user/php-src/Zend/zend_portability.h", line 251: Warning (Anachronism): Attempt to redefine __restrict__ without using #undef.
20 Error(s) and 1 Warning(s) detected.
gmake: *** [ext/intl/intl_convertcpp.lo] Error 1

Thanks for the further info. That's definitely a different error now. But unfortunately I don't see a starting point in the error output, as nothing points directly to the PHP sources :( I see also that this time gcc is used, whereby the initial error was about the Solaris compilers? Unfortunately i've no access to those compilers. Perhaps using a newer gcc or clang would produce a better result?

Thanks.

At long last, after much research, I have been able to compile PHP with the intl extension!!! I now believe that the root cause of the "isfinite" error and the subsequent compiling issues, is because the compiler was not seeing the GCC C++14 libraries. For instance, it couldn't see the C++14 version of /opt/developerstudio12.6/lib/compilers/include/CC/gnu/stddef.h, but the C version of /usr/include/stddef.h instead.

Normally, I would add "-I/opt/developerstudio12.6/lib/compilers/include/CC/gnu" to CXXFLAGS. However, this did not work, because the configure script gets "-I/usr/include" from the ICU config (C), stores it in ICU_CONFIG, then "-I/usr/include" gets injected into the libtool C++ compile command, before CXXFLAGS is injected. In order to inject the GCC C++14 system include earlier, I had to change line 46158 of ./configure from:

PHP_INTL_CXX_FLAGS="$INTL_COMMON_FLAGS $ICU_CXXFLAGS"

to

PHP_INTL_CXX_FLAGS="-I/opt/developerstudio12.6/lib/compilers/include/CC/gnu $INTL_COMMON_FLAGS $ICU_CXXFLAGS"

Besides the change to ./configure, here are the steps I took:

export MAKE=gmake
export CC=cc
export CXX=CC
export CFLAGS="-m64"
export CPPFLAGS="-m64"
export CXXFLAGS="-m64 -std=c++14 -library=CrunG3"
export LIBS="-lgcc_s -lCrunG3 -lstdc++"
export LDFLAGS="-L/opt/developerstudio12.6/lib/compilers/CC-gcc/lib"
export LDFLAGS="$LDFLAGS -R/opt/developerstudio12.6/lib/compilers/CC-gcc/lib"
export LDFLAGS="-L/opt/developerstudio12.6/lib/compilers/amd64"
export LDFLAGS="$LDFLAGS -R/opt/developerstudio12.6/lib/compilers/amd64"

./configure --with-apxs2=/usr/local/apache2/bin/apxs --with-iconv=/usr/local --enable-intl --enable-inline-optimization --without-sqlite3 --without-pdo-sqlite

gmake


I was able to compile on v7.1.24-dev with the fix by ab@php.net on 2018-07-09. However, I was also able to compile on releases 7.1.22 and 7.1.23, *without* the fix from the development branch. Based on this new information, I don't believe the fix by ab@php.net on 2018-07-09 is necessary to fix this issue.

I'd like to propose something else, though... It would be nice, if in the Makefile that is generated by ./configure, the libtool C++ compile commands included CXXFLAGS before other options, so that I could easily add -I/opt/developerstudio12.6/lib/compilers/include/CC/gnu into CXXFLAGS, instead of having to hacking up ./configure (bad practice) to make it work.

But I defer to the community's expertise on how to affect the build system. Any additional thoughts on how to solve this?