|  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: 2018-09-05 21:19 UTC
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: Re-Opened 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.
 [2018-07-09 22:38 UTC]
-Status: Open +Status: Feedback
 [2018-07-09 22:38 UTC]
@john, please check the latest dev branches with C++11 and up. A fix was pushed.

 [2018-09-05 18:21 UTC]
-Status: Feedback +Status: No Feedback -Assigned To: +Assigned To: cmb
 [2018-09-05 18:21 UTC]
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.
 [2018-09-05 19:04 UTC] john dot woods at greatplainsmfg dot com
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.
 [2018-09-05 21:19 UTC]
-Status: No Feedback +Status: Re-Opened -Assigned To: cmb +Assigned To:
 [2018-09-05 21:19 UTC]
Thanks!  Re-opening.
PHP Copyright © 2001-2018 The PHP Group
All rights reserved.
Last updated: Sun Sep 23 02:01:25 2018 UTC