qt4-mac: lots of errors trying to build with clang-7.0 (presumably related to defaulting to c++17 mode)

[kencu (Ken)]

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.

[kencu (Ken)]

There are lots of fixes in this repo, eg:

see: https://github.com/kobolabs/qtscript/commit/15bb30b0e90c628cc3812627923d1d459d461505
see: https://github.com/kobolabs/qtscript/commit/a2da34be8426b41047f895a3e8463d58baf3b576
see: https://github.com/kobolabs/qtscript/commit/b910624473344def2ef51c982c8a9a2431b8592a

I don't think they ever got to the end of the fixes, but maybe they did.

[kencu (Ken)]

some patches in an attempt to enable building with clang-7.0

[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!

[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.

[kencu (Ken)]

will do :>

[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.

[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

[kencu (Ken)]

that's a great effort! thanks...I guess we wrap these up into one big compat patch...

[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

[ryandesign (Ryan Carsten Schmidt)]

Now that we are defaulting to clang 9.0 on Snow Leopard, qt4-mac doesn't build there anymore:

​https://build.macports.org/builders/ports-10.6_x86_64-builder/builds/4114/steps/install-dependencies/logs/stdio

This is sad since Snow Leopard is probably one of the systems on which qt4-mac would be most useful.

[kencu (Ken)]

It builds just fine with clang-5.0. Not sure where the cutoff is between the two.

[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...

[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.

[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!

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

There is a ​pull request that attempts to solve this problem.

[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...

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

In 532963a6177616e80b43856db1390107636fff7f/macports-ports (master):

qt4-mac: allow newer compilers on older systems

Fixes #57751