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).
I worked it around by applying this: -using std::isnan; +extern "C" int isnan(double);
Confirmed: Robin's fix allows the file to build correctly.
Created attachment 2308 [details] proposed fix
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.
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.
This solution is the one that the Xcode Tools team suggested, fwiw.
(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
I think this is fixed in TOT.
Seems to work ok on TOT.