Bug 3344 – 10.3.9 Build Failure: isnan failure in kjs_window.cpp

• Status: RESOLVED
• Resolution: WORKSFORME
• Component: JavaScriptCore

[Christopher Schmidt]

Another build error: in file:
/Users/crschmidt/webkit/WebCore/khtml/ecma/kjs_window.cpp

/Users/crschmidt/webkit/WebCore/khtml/ecma/kjs_window.cpp:93: error: `isnan' not
declared
/Users/crschmidt/webkit/WebCore/khtml/ecma/kjs_window.cpp: In function `int
KJS::intFeature(const QMap<QString, QString>&, const char*, int, int, int)':
/Users/crschmidt/webkit/WebCore/khtml/ecma/kjs_window.cpp:557: error: `isnan'
undeclared (first use this function)
/Users/crschmidt/webkit/WebCore/khtml/ecma/kjs_window.cpp:557: error: (Each
undeclared identifier is reported only once for each function it appears in.)

Interestingly enough, there seems to be some kind of indication in the file of
why this might happen: 

// Must include <cmath> instead of <math.h> because of a bug in the
// gcc 3.3 library version of <math.h> where if you include both
// <cmath> and <math.h> the macros necessary for functions like
// isnan are not defined.

But <cmath> is being included. Not sure why exactly this is/isn't working, but I
do know that Panther is using gcc-3.3, whereas building on Tiger used gcc-4.0.

This one is an error, rather than a warning, so it can't be just skipped over.

I was able to continue building by pulling the isnan calls out (as well as the
using std::isnan), although obviously the code in this file will suffer as a
result. (Not sure what the end result of this really is, just trying to get it
to build to find where things which need to change are).

(Brought over from Bug 3331).

[Robin Lu]

I worked it around by applying this:

-using std::isnan;
+extern "C" int isnan(double);

[Christopher Schmidt]

Confirmed: Robin's fix allows the file to build correctly.

[Finlay Dobbie]

Created attachment 2308 [details]
proposed fix

[Harri Porten]

FWIW, the KDE version already uses an easy fix for this problem. The code is 
#ifdefed with HAVE_FLOAT_H. It's just that it's also protected 
by !APPLE_CHANGES so I think all that's needed is to apply the same change to 
operations.h. 

[Darin Adler]

Comment on attachment 2308 [details]
proposed fix

I don't like solutions that involve changing the project file, because it makes
it likely that we'll never remember to remove the hack. Also, setting the
internal _GLIBCPP flag in the project file is not how the library's intended to
be used.

There must be some other solution to compiling this on Panther. I'd prefer
another approach.

If we search and can't come up with anything, then feel free to set the review
flag on this patch again and I'll reconsider.

[Finlay Dobbie]

This solution is the one that the Xcode Tools team suggested, fwiw.

[Finlay Dobbie]

(In reply to comment #6)
> This solution is the one that the Xcode Tools team suggested, fwiw.

Just to clarify: this suggestion was made by Chris Espinosa and seemingly endorsed by Scott Tooker on 
the xcode-users mailing list, and not necessarily the position of the Xcode Tools team. See http://
lists.apple.com/archives/xcode-users/2005/May/msg00765.html

[Darin Adler]

I think this is fixed in TOT.

[Maciej Stachowiak]

Seems to work ok on TOT.