php.net |  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-10-23 16:06 UTC
Votes:1
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 11.3.21.5.0 (x86-64)
Private report: No CVE-ID: None
 [2017-07-11 16:06 UTC] john dot woods at greatplainsmfg dot com
Description:
------------
We are compiling PHP 7.1.7 on Solaris 11.3.21.5.0 + 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/configure.in). 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/preloadable_libiconv.so
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

make


Patches

Pull Requests

History

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

Thanks.
 [2018-09-05 18:21 UTC] cmb@php.net
-Status: Feedback +Status: No Feedback -Assigned To: +Assigned To: cmb
 [2018-09-05 18:21 UTC] cmb@php.net
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] cmb@php.net
-Status: No Feedback +Status: Re-Opened -Assigned To: cmb +Assigned To:
 [2018-09-05 21:19 UTC] cmb@php.net
Thanks!  Re-opening.
 [2018-10-04 19:23 UTC] ab@php.net
-Status: Re-Opened +Status: Feedback
 [2018-10-04 19:23 UTC] 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-10-08 15:43 UTC] john dot woods at greatplainsmfg dot com
-Status: Feedback +Status: Open
 [2018-10-08 15:43 UTC] 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-18 22:48 UTC] 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-23 16:06 UTC] john dot woods at greatplainsmfg dot com
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?
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Tue Oct 08 15:01:27 2024 UTC