|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #74904 zend_operators.h: Error: The function "isfinite" must have a prototype.
Submitted: 2017-07-11 16:06 UTC Modified: -
Avg. Score:1.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:0 (0.0%)
Same OS:0 (0.0%)
From: john dot woods at greatplainsmfg dot com Assigned:
Status: Open Package: Compile Failure
PHP Version: 7.1.7 OS: Solaris (x86-64)
Private report: No CVE-ID: None
Have you experienced this issue?
Rate the importance of this bug to you:

 [2017-07-11 16:06 UTC] john dot woods at greatplainsmfg dot com
We are compiling PHP 7.1.7 on Solaris + idr3199, using Solaris Studio 12.5 compilers.

During the build of the ./ext/intl extension, the following libtool command fails to build ext/intl/intl_convertcpp.lo:

/bin/sh /tmp/SOURCE_DIR/libtool --silent --preserve-dup-deps --mode=compile CC -I/usr/include  -Wno-write-strings -D__STDC_LIMIT_MACROS -DZEND_ENABLE_STATIC_TSRMLS_CACHE=1 -Iext/intl/ -I/tmp/SOURCE_DIR/ext/intl/ -DPHP_ATOM_INC -I/tmp/SOURCE_DIR/include -I/tmp/SOURCE_DIR/main -I/tmp/SOURCE_DIR -I/tmp/SOURCE_DIR/ext/date/lib -I/usr/include/libxml2 -I/usr/local/include -I/tmp/SOURCE_DIR/ext/sqlite3/libsqlite -I/tmp/SOURCE_DIR/TSRM -I/tmp/SOURCE_DIR/Zend  -D_POSIX_PTHREAD_SEMANTICS  -g  -c /tmp/SOURCE_DIR/ext/intl/intl_convertcpp.cpp -o ext/intl/intl_convertcpp.lo
"/tmp/SOURCE_DIR/Zend/zend_portability.h", line 251: Warning (Anachronism): Attempt to redefine __restrict__ without using #undef.
"/tmp/SOURCE_DIR/Zend/zend_operators.h", line 117: Error: The function "isfinite" must have a prototype.
"/tmp/SOURCE_DIR/Zend/zend_operators.h", line 128: Error: The function "isfinite" must have a prototype.
2 Error(s) and 1 Warning(s) detected.
*** Error code 1
make: Fatal error: Command failed for target `ext/intl/intl_convertcpp.lo'

Upon investigation, the "isfinite" comes from zend_finite(), which gets #define(d) as "isfinite" only if HAVE_DECL_ISFINITE is true (lines 93-101 of Zend/ The HAVE_DECL_ISFINITE is set by the main configure script, if "isfinite" is defined by #include(ing) <math.h>.

I'm convinced that the root of this problem is that "isfinite" is a valid function with Solaris Studio's C compiler. But with the C++ compiler, "std::isfinite" is not defined, since the default C++ dialect is C++ 03. The file it is trying to build is ext/intl/intl_convertcpp.cpp.

I tried adding "-std=sun03" or "-std=c++03" to CXXFLAGS, but still had the problem. I also tried setting the flags to "-std=c++11" and "-std=c++14", to force the C++ 11 or C++ 14 dialect, but those options prevented linking to the GCC/G++ libraries, which caused other compile problems.

The only way I could get this to compile and work, was forcing HAVE_DECL_ISFINITE, HAVE_DECL_ISNAN, and HAVE_DECL_ISINF to be 0 in the main configure script, to avoid this altogether. I know it's a bad hack, but it did actually work around the issue.

I don't believe this is a duplicate of Bug #74265, since this is a C++ issue.

Test script:
export CC=cc
export CPP="CC -E"
export CXX=CC
export CFLAGS="-m64 -std=c11"
export CPPFLAGS="-m64"
export CXXFLAGS="-m64"
export LD_PRELOAD_64=/usr/local/lib/
export LD_LIBRARY_PATH=/usr/local/lib

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



Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2017-07-11 16:11 UTC] spam2 at rhsoft dot net
-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
 [2017-07-11 16:13 UTC] spam2 at rhsoft dot net
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]
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.
 [2017-07-11 16:31 UTC] john dot woods at greatplainsmfg dot com
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.
 [2017-07-11 19:00 UTC] john dot woods at greatplainsmfg dot com
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.
 [2017-07-11 19:23 UTC] spam2 at rhsoft dot net
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
 [2017-07-11 19:48 UTC] john dot woods at greatplainsmfg dot com
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.
PHP Copyright © 2001-2018 The PHP Group
All rights reserved.
Last updated: Sun Nov 19 01:31:42 2017 UTC