Opened 6 years ago
Closed 5 years ago
#57751 closed defect (fixed)
qt4-mac: lots of errors trying to build with clang-7.0 (presumably related to defaulting to c++17 mode)
Reported by: | kencu (Ken) | Owned by: | michaelld (Michael Dickens) |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | |
Keywords: | Cc: | devernay (Frédéric Devernay), MarcusCalhoun-Lopez (Marcus Calhoun-Lopez) | |
Port: | qt4-mac |
Description
there are chunks of qt4-mac that just don't build with clang-7.0.
Not a lot of point attaching a log as it's whack-a-mole -- you fix some and find more.
Some groups around the web have worked on this, and there are some fixes out there if interested. I'll attach the patches I had figured out until I ran across something I didn't know how to fix in the javascript core:
In file included from wtf/DateMath.cpp:79: In file included from runtime/JSObject.h:26: In file included from runtime/ArgList.h:25: In file included from interpreter/CallFrame.h:26: In file included from runtime/JSGlobalData.h:33: In file included from heap/Heap.h:27: In file included from heap/MarkStack.h:32: ./wtf/HashSet.h:191:16: error: no viable conversion from returned value of type 'pair<WTF::HashTable<void *, void *, WTF::IdentityExtractor<void *>, WTF::PtrHash<void *>, WTF::HashTraits<void *>, WTF::HashTraits<void *> >::iterator, [...]>' to function return type 'pair<WTF::HashSet<void *, WTF::PtrHash<void *>, WTF::HashTraits<void *> >::iterator, [...]>' return m_impl.add(value); ^~~~~~~~~~~~~~~~~
Or maybe I just ran out of steam.
I think the best idea may be to force down the standard rather than fix all these compilation errors. I think I'm seeing it in clang-7.0 because it defaults to a higher standard.
Attachments (18)
Change History (36)
comment:1 Changed 6 years ago by kencu (Ken)
Changed 6 years ago by kencu (Ken)
Attachment: | patch-qt4-mac-cpp11-attempts.diff added |
---|
some patches in an attempt to enable building with clang-7.0
comment:2 Changed 6 years ago by michaelld (Michael Dickens)
LOL I don't think we ever got qt4-mac working with c++11 and clang! I can help test, but I doubt I'll have the bandwidth to do much in the way of whack-a-mole fixing. We'll see how my December unfolds!
comment:3 Changed 6 years ago by michaelld (Michael Dickens)
Maybe let's make a branch in your GitHub account for this & make sure I can write to it. That way we can just keep pushing fixes. Once (if) we get this working, we can manipulate / squash commits.
comment:5 Changed 6 years ago by Veence (Vincent)
WTF::HashTable …
On the other hand, if you try compile a class named WTF…
Any speculative schedule for the porting of Qt 5.12 just released? It’s the first version to officially support New 10.14 dark mode.
comment:6 Changed 5 years ago by devernay (Frédéric Devernay)
Cc: | devernay added |
---|
comment:7 Changed 5 years ago by devernay (Frédéric Devernay)
I got it to compile and run with clang-8.0 (on OSX 10.6)
Here's what I did:
- applied kencu's patch
- applied the patches from http://openbsd-archive.7691.n7.nabble.com/lang-gcc-8-can-t-build-x11-qt4-td359804.html except the following (already in kencu's):
- patch-src_3rdparty_javascriptcore_JavaScriptCore_runtime_Structure_cpp
- patch-src_3rdparty_javascriptcore_JavaScriptCore_runtime_Structure_h
- made a few more patches:
- patch-src_3rdparty_webkit_Source_JavaScriptCore_runtime_StringPrototype_cpp
- patch-src_3rdparty_webkit_Source_JavaScriptCore_runtime_JSONObject_cpp
- patch-src_3rdparty_webkit_Source_JavaScriptCore_runtime_Identifier_cpp
- patch-src_3rdparty_webkit_Source_JavaScriptCore_bytecompiler_BytecodeGenerator.cpp
- patch-src_3rdparty_webkit_Source_JavaScriptCore_wtf_text_AtomicString_cpp
- patch-src_3rdparty_webkit_Source_WebCore_dom_DocumentMarkerController_cpp
- moved src/3rdparty/javascriptcore/VERSION to src/3rdparty/javascriptcore/VERSION.txt (because src/3rdparty/javascriptcore is in the include path, and someone does #include <version> - remember that the filesystem is not case sensitive)
I'm attaching all the patches to this ticket.
I think it would be better to *not* build qtwebkit, have a separate port with the more recent qtwebkit from https://download.kde.org/stable/qtwebkit-2.3/2.3.4/src/qtwebkit-2.3.4.tar.gz - see https://github.com/cartr/homebrew-qt4/blob/master/qt-webkit%402.3.rb
Changed 5 years ago by devernay (Frédéric Devernay)
Attachment: | patch-src_3rdparty_javascriptcore_JavaScriptCore_runtime_Structure_cpp added |
---|
Changed 5 years ago by devernay (Frédéric Devernay)
Attachment: | patch-src_3rdparty_javascriptcore_JavaScriptCore_runtime_Structure_h added |
---|
Changed 5 years ago by devernay (Frédéric Devernay)
Attachment: | patch-src_3rdparty_javascriptcore_JavaScriptCore_wtf_HashTable_h added |
---|
Changed 5 years ago by devernay (Frédéric Devernay)
Attachment: | patch-src_3rdparty_javascriptcore_JavaScriptCore_wtf_MathExtras_h added |
---|
Changed 5 years ago by devernay (Frédéric Devernay)
Attachment: | patch-src_3rdparty_javascriptcore_JavaScriptCore_wtf_TypeTraits_h added |
---|
Changed 5 years ago by devernay (Frédéric Devernay)
Changed 5 years ago by devernay (Frédéric Devernay)
Attachment: | patch-src_3rdparty_webkit_Source_JavaScriptCore_runtime_Identifier_cpp added |
---|
Changed 5 years ago by devernay (Frédéric Devernay)
Attachment: | patch-src_3rdparty_webkit_Source_JavaScriptCore_runtime_JSONObject_cpp added |
---|
Changed 5 years ago by devernay (Frédéric Devernay)
Changed 5 years ago by devernay (Frédéric Devernay)
Attachment: | patch-src_3rdparty_webkit_Source_JavaScriptCore_wtf_HashSet_h added |
---|
Changed 5 years ago by devernay (Frédéric Devernay)
Attachment: | patch-src_3rdparty_webkit_Source_JavaScriptCore_wtf_MathExtras_h added |
---|
Changed 5 years ago by devernay (Frédéric Devernay)
Changed 5 years ago by devernay (Frédéric Devernay)
Attachment: | patch-src_3rdparty_webkit_Source_JavaScriptCore_wtf_TypeTraits_h added |
---|
Changed 5 years ago by devernay (Frédéric Devernay)
Changed 5 years ago by devernay (Frédéric Devernay)
Attachment: | patch-src_3rdparty_webkit_Source_WebCore_dom_Element_cpp added |
---|
Changed 5 years ago by devernay (Frédéric Devernay)
Attachment: | patch-src_plugins_accessible_widgets_itemviews_cpp added |
---|
Changed 5 years ago by devernay (Frédéric Devernay)
Attachment: | patch-src_xmlpatterns_api_qcoloroutput_p_h added |
---|
comment:8 Changed 5 years ago by kencu (Ken)
that's a great effort! thanks...I guess we wrap these up into one big compat patch...
comment:9 Changed 5 years ago by devernay (Frédéric Devernay)
sure, that would make sense. don't forget the part that renames or removes src/3rdparty/javascriptcore/VERSION I do that at the end of post-patch:
# <cstddef> from libc++ includes <version>, and src/3rdparty/javascriptcore is in the include path. # Since macOS is (most of the time) case insensitive, this causes the build to fail. delete ${worksrcpath}/src/3rdparty/javascriptcore/VERSION
comment:10 Changed 5 years ago by ryandesign (Ryan Carsten Schmidt)
Now that we are defaulting to clang 9.0 on Snow Leopard, qt4-mac doesn't build there anymore:
This is sad since Snow Leopard is probably one of the systems on which qt4-mac would be most useful.
comment:11 Changed 5 years ago by kencu (Ken)
It builds just fine with clang-5.0. Not sure where the cutoff is between the two.
comment:12 Changed 5 years ago by kencu (Ken)
Hmmm. This block is supposed to be blacklisting clang-9.0:
compiler.blacklist-append { clang <= 503 } \ gcc-3.3 *gcc-4.0 macports-gcc* \ { macports-clang-[6-9].0 }
I wonder why the port is still trying to build with clang-9.0 despite this.
It says:
Warning: All compilers are either blacklisted or unavailable; defaulting to first fallback option
but -- clang-5.0 is supposed to be on the compiler list for 10.6.8
...
comment:13 Changed 5 years ago by MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)
Cc: | MarcusCalhoun-Lopez added |
---|
comment:14 Changed 5 years ago by kencu (Ken)
btw marcus, the fix for that was to get rid of the spaces: {macports-clang-[6-9].0}
, and now qt4-mac asks for clang-5.0
. I am pretty sure clang-6.0
is OK to build it too, but haven't tried. clang-7.0
and above, likely not.
I tried a build with all of the patches, but still failed. Haven't dug back in more. Like Michael says, it's probably about time one of us busted qt4-mac
into our own github repo somewhere and started adding the patches that way, as it's getting very unwieldy in the Portfile / patchfile sense.
comment:15 Changed 5 years ago by michaelld (Michael Dickens)
@kencu: I'm all for busting qt4-mac ... not enough time in the day for me to own and/or maintain that repo. Maybe you have the bandwidth? There are projects that keep using Qt4, since it does work pretty decently still after all these years with just newer compiler & OS fixes but no real code development. My primary worry would be licensing issues. IT's such a sensitive topic these days!
comment:16 Changed 5 years ago by MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)
There is a pull request that attempts to solve this problem.
comment:17 Changed 5 years ago by kencu (Ken)
I also pondered whether forcing the older standard might be easier that updating the code to the new standard ... good plan, I think, for the forseeable future anyway...until/unless we run into a c++11 required dep,I suppose...
comment:18 Changed 5 years ago by MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
There are lots of fixes in this repo, eg:
I don't think they ever got to the end of the fixes, but maybe they did.