Stefan Teleman wrote: > Paul Floyd wrote: >> I just wrote what I read. > > Not really. You wrote *some* of what you read: > > http://doc.trolltech.com/4.4/supported-platforms.html > > Supported Features: > > Compiler Features > Concurrent XmlPatterns WebKit CLucene Phonon > > [ ... ] > SunCC <= 5.6 X X X > SunCC 5.7 & 5.8 X X X X > SunCC 5.9 and X X X X X > up
I'd have no beef if the third X from the end of that last line weren't there. >> Qt 4.4.0 is the first version of Qt that I've used that won't build >> out of the box on Solaris with the Sun compiler. > > WebKit was introduced *first* in QT 4.4.0, and it is WebKit which is > where the vast majority of compile failures were reported. The compile > failures in qmake are caused by your $(CXXFLAGS) not passing > -D_XOPEN_SOURCE=500. This define is mandatory, and not only for QT. Here's a rough list of the files I changed in building Qt: find . -name "*~" ./src/corelib/thread/thread.pri~ ./src/3rdparty/webkit/JavaScriptCore/kjs/math_object.cpp~ ./src/3rdparty/webkit/JavaScriptCore/kjs/date_object.cpp~ ./src/3rdparty/webkit/JavaScriptCore/kjs/operations.cpp~ ./src/3rdparty/webkit/JavaScriptCore/kjs/collector.cpp~ ./src/3rdparty/webkit/JavaScriptCore/API/JSObjectRef.h~ ./src/3rdparty/webkit/JavaScriptCore/API/JSValueRef.h~ ./src/3rdparty/webkit/JavaScriptCore/API/JSBase.h~ ./src/3rdparty/webkit/JavaScriptCore/API/JSContextRef.h~ ./src/3rdparty/webkit/JavaScriptCore/API/JSStringRef.h~ ./src/3rdparty/webkit/WebCore/dom/QualifiedName.cpp~ ./src/3rdparty/webkit/WebCore/ksvg2/svg/SVGPathElement.cpp~ ./src/3rdparty/webkit/WebCore/ksvg2/svg/SVGPolyElement.cpp~ ./src/3rdparty/webkit/WebCore/css/CSSSelector.cpp~ ./src/3rdparty/webkit/WebCore/css/CSSStyleSelector.cpp~ ./src/3rdparty/webkit/WebCore/xml/XPathValue.cpp~ ./src/3rdparty/webkit/WebCore/xml/XPathFunctions.cpp~ ./src/3rdparty/webkit/WebCore/editing/markup.cpp~ ./src/3rdparty/webkit/WebCore/html/HTMLInputElement.cpp~ ./src/3rdparty/webkit/WebCore/html/HTMLParser.cpp~ ./mkspecs/solaris-cc/qmake.conf~ (I probably edited a few files with vi, so no ~ traces). They're all in webkit apart from the thread profile include file. I expect that _XOPEN_SOURCE will fix one problem with munmap. > Modulo the overloading ambiguity compile failure in the example you > mentioned earlier. I have not had the time to look into it thoroughly, > and i have not yet determined that it is indeed a QT 4.4.x bug or a > Studio 12 bug. There's one other resolution problem, which could be a Studio problem, and a few that are operator+ ambiguities between String and QString (easily fixed by explicitly creating String instances). Most of the remaining errors are GCC (and perhaps other compilers) nonstandard code: use of "__inline" and using C99 features in C++ [including "<stdbool.h>", use of mathematical macros like isfinite] The use of stdbool.h is probably the only one that might be dangerous (since sizeof(C++ bool) is different to sizeof(C99 _Bool)). > Reporting compiler failures for WebKit along with suggested fixes is the > right thing to do. Just because you ran into compile failures in 4.4.0 > and you reported them, it doesn't mean that they won't be fixed in > 4.4.1, or that "Solaris is no longer supported", or that "TT developers > no longer have Solaris workstations". Maybe it takes time to synchronize > compiler fixes for WebKit between TT and upst I don't really know what the relationship is between Trolltech/Qt and KDE/WebKit. If TT doesn't own (or hasn't forked) WebKit, then I can see that they are going to have problems supporting it. > Do you still compile QT4 with SunCC 5.6 ? No, just Studio 12 and Express. A+ Paul -- Paul Floyd http://paulf.free.fr
