Created attachment 197800 [details]
compiler:c++17-lang, usual treatment.
Tested on powerpc64 and amd64.
Hardware sponsored by IntegriCloud.
Have you ever checked why these need c++17 and not 11?
(In reply to Tobias C. Berner from comment #1)
They require it, because Qt's build system adds -std=c++1z to compilation flags. I didn't push it further, if it says it needs c++1z (which is C++17), then so be it.
Hm, interesting, I was under the impression that it only requires c++11.
I'll do some investigating, and then commit the bunch...
I think this does not address the right issue -- it should not require anything higher than c++11 to build Qt5. So something probably goes wrong in the configure script, which is what we need to fix.
Created attachment 197852 [details]
build log from powerpc64
For reference, I'm attaching a build log which clearly shows added -std=c++1z.
I'm not doubting it adds it.
The problem is it adds it, because you build it with a compiler that supports it (I think [tm]). But that should not "force" c++17 on the rest of the builders.
We need to see how to tell qmake to ignore the spec, and only use c++11, when building the qt5-* ports.
As the build already pulls in the right gcc, I think it should be save to just set USES=c++11-lang.
Could you test?
(In reply to Tobias C. Berner from comment #7)
Yes, it works. You can just as well put c++11-lang. It works the same in that it forces GCC 7, but in the present state, it's a lie (the port uses C++17).
(In reply to Piotr Kubaj from comment #8)
I would prefer if the "forcing" is done explicitely in the change to qt-dist.mk/qt5-qmake by depending on a specific [possibly configurable] version of gcc -- not via USES=compiler.
(In reply to Tobias C. Berner from comment #9)
Using USES has the advantage that we get newer GCC when the default version in ports is changed.
Anyway, do you suggest we add our own BUILD_DEPENDS and LIB_DEPENDS entries for newer GCC?
The thing is, Qt does not care about the compiler you give it, but will use the compiler from the mkspec generally.
So we need to make sure that we depend on that one, when USES=qmake is present. This is what I was suggesting in the qt5-qmake PR 231542.
(In reply to Tobias C. Berner from comment #6)
wr/t forcing c++17 onto kde5 on the rest of the builders:
- kde5 does not build on mips64 due to wayland
- kde5 does not build on armv6 due to plasma5-kinfocenter
- kde5 does not build on aarch64 due to grantlee5
some IMHO we're optimizing for what are already nonworking cases.
I haven't done the research to figure out if the dependencies already depend on gcc7 on mips64, but I am going to assume so.
I'm back working on FreeBSD after a few days away. I'll try to come up with a gerernal patch, but I think we're making extra work for ourselves.
(In reply to Mark Linimon from comment #12)
I do _not_ want c++17 added (as that might imply additional dependencies on older clang systems).
I would prefer just to add USES=c++11-lang/lib to all the qt5 ports if that is enough.
(In reply to Mark Linimon from comment #12)
The general patch would be to add USES to qt-dist.mk. I didn't want to do it, since I thought there may be some Qt5 ports that would compile with base GCC. I can see it was rather futile now.
We could add USES=c++11-lang to qt-dist.mk along with EXTRA_PATCHES (or USE_GCC, like you said in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231542 ).
(In reply to Tobias C. Berner from comment #13)
Just want to note that the only "older clang system" right now is 10.4-RELEASE which will go EOL in 24 days. Still, I don't mind it myself if you just put compiler:c++11-lang. Regarding Qt not caring about CC and CXX - my patch at https://bz-attachments.freebsd.org/attachment.cgi?id=197515 already takes care of that (seding QMAKE_* values)
(In reply to Piotr Kubaj from comment #14)
With that sed you just set what it cares about. But if you decide that you now want GCC_DEFAULT=9 aftwards, you'll still be building qt with the gcc7 you had previously when building qmake.
But the minimal approach with these patches, using c++11-lib and adding USE_GCC seems like the most appropriate fix at the moment -- if it works, that is :)
(In reply to Tobias C. Berner from comment #15)
You can change GCC version via make.conf.
This approach works, yes. Could you commit it?
Piotr, could you send me a single diff, of the changes in the qt5-* ports and qt*mk files?
Created attachment 197906 [details]
Here's a complete (as of now) patch. Note that as I fix ports, another ports dependant on the fixed ones try to build, so there will be more fixes.
This patch also contains fixes for some other ports maintained by @kde.
The full list of patched ports:
(In reply to Tobias C. Berner from comment #17)
Any info about committing this patch? I already have other ports to fix, but I'd like to get this committed first.
A commit references this bug:
Date: Sun Oct 14 08:01:25 UTC 2018
New revision: 482034
qt5: Fix build on GCC based architectures.
Submitted by: Piotr Kubaj <email@example.com>