Edit report at https://bugs.php.net/bug.php?id=76826&edit=1
ID: 76826
Updated by: ab@php.net
Reported by: php-bugs-2018 at ryandesign dot com
Summary: error: use of undeclared identifier 'finite'
-Status: Open
+Status: Feedback
Type: Bug
Package: Compile Failure
Operating System: Mac OS X 10.7.5
PHP Version: 7.2.9
Block user comment: N
Private report: N
New Comment:
Thanks for the detailed analysis. The finite family is with this regardobsolete because C99 defines
isfinite, the man page says, but all the current PHP versions don't use strict C99. In how far
isfinite is better or finite is worse, is another question.
This issue seems to show up in quite different constellations, it is hard to find a middle ground.
There was same issue reported in bug #74904 on Solaris, which was fixed by the existing patch
(though other C++ issues arise). I with this regardwas able to reproduce this issue with older
versions of gcc on Linux, too. Namely from gcc 4.9.x to gcc 5.x.x.
Now, on the Apple side, not sure whether C99 is default, but isfinite should definitely not be there
when C++11 or up is compiled. With C++ it has to be std::isfinite from cmath. On some gcc versions
however, including cmath brings another can of bugs, so the best way looks like to avoid it for now.
The facts you depict confirm as well, that this math.h vs. cmath/C++ topics in regard to differnet
platforms and compiler versions are handled in very different ways and a diligence is due to keep
and improve the compatibility. Were you able also to check the attached patch, which makes an
exception for the Apple platform? If Apple allows isfinite even if C++11 is compiled, then that
might be the way to solve it for that platform.
We might have it easier, when PHP has switched to C99. That however is to be checked and anyway
won't affect already released branches.
Thanks.
Previous Comments:
------------------------------------------------------------------------
[2018-10-16 01:07:53] php-bugs-2018 at ryandesign dot com
I am not a C++ programmer but from what I've been able to research, "finite" is an
old deprecated method of determining if a number is finite, and "isfinite" is its
replacement, available as of C99.
Given that, the PHP code used to make sense: It used to use "isfinite" if it was
available, and otherwise it would use "finite" if that was available. The change in
ad790bea2e4a8a25c79ceab964601f3785cd2bf1 seems wrong to me, because now, if compiling in C++11 mode
or newer, the newer "isfinite" method isn't used, and the deprecated
"finite" is used instead. Why would we want to use a deprecated function when a newer
replacement function is available, especially if we're compiling in a newer language mode?
The reason for the compile failure I reported appears to be that the intl extension uses icu, and
used icu-config --cxxflags to get the flags it should use. We're using icu 58.2 in
MacPorts, and it returns "--std=c++0x". (Yes, there is a typo: it should be one dash
instead of two, but the compiler still recognizes the flag despite that.) The intl extension was
changed in 4acc8500acd134dfab1a2ddb83aeb39fa1033abe on 9/28/2018 to always use C++11 mode regardless
what ICU says. So we're in C++11 mode and __cplusplus is 201103L which is why PHP is now trying
(misguidedly, in my opinion) to use "finite" here. I've also seen the same problem
when building the third-party swoole extension, which also uses C++11.
So why doesn't "finite" exist, even though HAVE_FINITE is 1? On Mac OS X 10.7,
/usr/include/math.h is just a wrapper that includes /usr/include/architecture/i386/math.h, and in
that file, the definition of "finite" and other deprecated functions is inside a block
which checks:
#if !defined( __STRICT_ANSI__) && !defined(_ANSI_SOURCE) &&
(!defined(_POSIX_C_SOURCE) || defined(_DARWIN_C_SOURCE))
And it turns out that __STRICT_ANSI__ is defined (due, I believe, to requesting conformance to an
ISO C/C++ standard, in this case c++0x), therefore these legacy functions don't get defined. I
can get the build to succeed on 10.7 by undefining __STRICT_ANSI__ (e.g. by adding
"-U__STRICT_ANSI__" to CXXFLAGS), though I don't know what other implications that
might have elsewhere in the system headers so I don't think this is the solution we want to
use.
In OS X 10.8, Apple moved the header to /usr/include/math.h and rewrote it so that it only checks:
#if __DARWIN_C_LEVEL >= __DARWIN_C_FULL
__DARWIN_C_LEVEL is defined to be __DARWIN_C_FULL so on 10.8 and later old "finite" is
still available in strict ANSI mode.
As for why it also built successfully on 10.6, that's because on that system icu-config
--cxxflags returns nothing, because the old g++ 4.2.1 compiler on that system doesn't
have any C++11 support. Therefore we're not in strict ANSI mode, therefore the deprecated
functions are still defined.
I have tried reverting ad790bea2e4a8a25c79ceab964601f3785cd2bf1 and it builds successfully on 10.7,
and still builds fine on 10.13, despite the fact that the commit message for
ad790bea2e4a8a25c79ceab964601f3785cd2bf1 says that "isfinite" was supposed to have moved
into the std namespace as of C++11. Further research tells me that "isfinite" and friends
are only in the std namespace if you #include <cmath>. PHP doesn't do that; instead, it
includes the older <math.h>, in which case those functions are not in the std namespace. I
believe this confirms my suspicion that ad790bea2e4a8a25c79ceab964601f3785cd2bf1 doesn't do
anything useful and should be reverted.
------------------------------------------------------------------------
[2018-10-13 07:28:37] elis at hirwing dot se
@ab - I think the reason for the patch not applying was because the lines it tried to remove
wasn't there in that version of the source that it tried to patch. It also seems to differ
between 7.1.X and 7.2.X what they look like.
Make sure to take a copy of the log if you have use for it since it will go away. Nothing I can do
about that :/
Also, could you lend me some pointer to how to subscribe to this issue. I've tried several
times to fill email, solve math-problem and press subscribe but haven't got a single message.
------------------------------------------------------------------------
[2018-10-11 22:26:12] ab@php.net
@elis yep, that's the same bug. Thanks for re-posting the log. I've no Mac as well, so
only able to guess the conditions. With the patch - you need to ensure the -p option has the correct
level number, depending on the CWD when the patch gets applied. Alternatively you can edit the paths
in the patch, so they suffice for the build constellation.
Thanks.
------------------------------------------------------------------------
[2018-10-11 21:15:10] elis at hirwing dot se
@ab I've completely missed the answers here. I have tried to build 7.2.11 and 7.1.23 which have
failed the same way.
Too bad it's the same log viewer as before: https://logs.nix.ci/?key=nixos/nixpkgs.48228&attempt_id=94e95849-958b-4b83-8952-90bc4cf3021f
-- but it's the only way I have to get the log out from the darwin builds since I don't
have any darwin machines myself.
I've also tried to apply your patch on 7.2.11 and 7.1.23 for darwin, but it didn't apply
at all: https://logs.nix.ci/?key=nixos/nixpkgs.48228&attempt_id=7d415ce6-e908-439e-bbf4-5fe6797871c8
------------------------------------------------------------------------
[2018-10-05 07:13:21] ab@php.net
Thanks for the build new logs. Is that with the vanilla package? Were you able to play with the
condition as i've suggested? Perhaps you could try the patch i've just attached. I'd
be really reluctant to do fixes for EOL versions, but at least we could figure out what goes wrong
there. Probably only you can do that, as the chances to find someone with this OSX version are
probably marginal.
Thanks.
------------------------------------------------------------------------
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=76826
--
Edit this bug report at https://bugs.php.net/bug.php?id=76826&edit=1