Edit report at https://bugs.php.net/bug.php?id=74904&edit=1
ID: 74904
User updated by: john dot woods at greatplainsmfg dot com
Reported by: john dot woods at greatplainsmfg dot com
Summary: zend_operators.h: Error: The function "isfinite"
must have a prototype.
Status: Open
Type: Bug
Package: Compile Failure
Operating System: Solaris 11.3.21.5.0 (x86-64)
PHP Version: 7.1.7
Block user comment: N
Private report: N
New Comment:
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?
Previous Comments:
------------------------------------------------------------------------
[2018-10-18 23:11:07] ab@php.net
Related To: Bug #76826
------------------------------------------------------------------------
[2018-10-18 22:48:45] ab@php.net
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.
------------------------------------------------------------------------
[2018-10-08 15:43:45] john dot woods at greatplainsmfg dot com
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
------------------------------------------------------------------------
[2018-10-04 19:23:22] ab@php.net
Which exact errors came up? If the originally reported error is fixed, those new should be reported
in a new ticket.
Thanks.
------------------------------------------------------------------------
[2018-09-05 21:19:09] cmb@php.net
Thanks! Re-opening.
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=74904
--
Edit this bug report at https://bugs.php.net/bug.php?id=74904&edit=1