Ticket #42402

Qt clients require c++11 (explicitly, on older macOS)

Open Date: 2021-05-27 10:29 Last Update: 2021-06-11 15:15

5 - Medium
5 - Medium


Freeciv's configure scripts refuse to enable the Qt client or modpack installer on older macOS systems. It seems that the Qt clients have code which requires the C++11 language standard. The automake scripts correctly test for this language support. The clang/LLVM compiler which Apple supplies with older macOS systems defaults to the C++98 standard, but supports newer standards when requested. Thus the configure scripts determine that the compiler is insufficient. The solution is to add an option to the automake scripts to instruct the compiler to use the C++11 language standard.

How to reproduce:

  1. On a macOS 10.13.6 High Sierra installation, install XCode, and MacPorts, and at least the autotools and qt5-qtbase ports. Maybe also need ports qt5-qtdeclarative, qt5-qtmacextras, qt5-qtmultimedia, qt5-qtsvg, qt5-qttools, qt5-qttranslations .
  2. export PATH=/opt/local/bin:/opt/local/libexec/qt5/bin/:${PATH} so that the freeciv build process sees both the autotools and the Qt5 utilities installed via MacPorts.
  3. % export LDFLAGS='-L/opt/local/libexec/qt5/lib -L/opt/local/lib' so that the freeciv build process sees both the autotools and the Qt5 libraries installed via MacPorts.
  4. Run autogen, with options you prefer. I used something like:
% ./autogen.sh --disable-silent-rules --enable-fcdb=sqlite3 --prefix=$HOME/opt/freeciv
 --with-readline --enable-sdl-mixer --enable-fcmp=qt  --enable-client=qt

Observed behaviour:

Configure fails with an error message, "selected client 'qt' cannot be built: Missing Qt5 development files".

This is the configure output, on branch S2_6 at least:

+ checking for autoconf >= 2.61 ... found 2.71, ok.
+ checking for autoheader >= 2.61 ... found 2.71, ok.
checking for qtpaths... qtpaths
checking Qt5 framework... not found
configure: error: selected client 'qt' cannot be built: Missing Qt5 development files

configure failed

Expected behaviour:

Configure succeeds with a message like, "Maintained client frontends: QT: yes".

This is successful configure output on S2_6:

+ checking for autoconf >= 2.61 ... found 2.71, ok.
+ checking for autoheader >= 2.61 ... found 2.71, ok.
****************** Configuration Summary ******************
  == Client ==
  Build freeciv client:  yes

  Maintained client frontends:
    Gtk-3.0:  no
    Gtk-2.0:  no
    Gtk-3.22: no
    SDL:      no
    QT:       yes
    Stub:     no

  == Tools ==
  Modpack installers:    qt
  Ruleset editor:        yes
  Manual generator:      wiki

Now type 'make' to compile freeciv.
Also expected: make all compiles apps freeciv-qt and freeciv-mp-qt .


The configuration error is raised by automake scripts in m4/qt5-darwin.m4. (Darwin refers to the macOS kernel.) macOS 10.13.6 High Sierra uses the Apple LLVM version 10.0.0 (clang-1000.11.45.5) compiler, rather than gcc. This compiler conforms to the c++98 standard by default. The Qt5 application code requires features from the c++11 standard. Compiler option -std=c++11 makes the clang compiler conform to the correct standard.

This apparently hasn't been an issue on Windows and Linux builds. I suspect that the reason is that the gcc defaults to the c++11 language standard. Qt5 code compiles without an explicit compiler option. Newer macOS versions have newer clang compilers, which might also default to the necessary language standard.

I believe the right way to fix this bug is to ensure that the automake scripts pass a -std=c++11 or the like to the compiler, as needed by the codebase being compiled. The automake scripts should not assume that the compiler will support the correct C++ language standard by default. I suspect that there is no harm to specifying the language standard even on platforms and compilers where the default is good enough. So, we could make automake scripts for all C++ clients specify the language standard. This is perhaps better. However, for me it is enough to fix the problem for macOS.

In S2_6, I see automake scripts ./m4/qt.m4 and ./m4/qt-darwin.m4 . qt-darwin.m4 seems to be the macOS alternative to qt.m4 . Both set a variable FC_QT5_CXXFLAGS. When I added " -std=c++11" to this code, it made the Qt client and modpack programs compile on macOS 10.13.6 High Sierra.

I have only glanced quickly at the S3_0, S3_1, and master branches. It looks like they have parallel automake structures.

master at least has code for a Qt6 client as well. Qt6 requires the C++17 language standard (source: https://www.qt.io/blog/qt-6.0-released ).

Ticket History (3/13 Histories)

2021-05-27 10:29 Updated by: jdlh
  • New Ticket "Qt clients require c++11 (explicitly, on older macOS)" created
2021-05-27 10:42 Updated by: cazfi

Would backporting https://www.hostedredmine.com/issues/880321 to S3_0 & S2_6 be sufficient?

2021-05-27 10:56 Updated by: jdlh

The patches in https://www.hostedredmine.com/issues/880321 look like way more than is necessary. They contain C++ test programs to evaluate which language specification the compiler supports. The freeciv automake scripts already have code which test this (for C++11 features, at least). All they lack is to assert -std=c++11 along with the other flags, presently -fPIC.

I have a patch for S2_6 which is just a few lines long. The issue 880321 patch is nearly 1000 lines long.

It might be that you like the test programs in the issue 880321 patch more than you like the test programs which freeciv currently uses. If so, change over. But I do not think that big a change is necessary to fix this ticket.

2021-05-27 11:02 Updated by: cazfi

The reason that it was not done for S3_0 & S2_6 is that in those branches we officially support older compilers, with (older) Qt versions that do not require C++-11.

2021-05-27 12:03 Updated by: jdlh

I think I have just configured and compiled the Qt5 client on branch master with no patches. So, once the PATH and LDFLAGs are right, that seems to be enough.

It looks like the makefiles can build either a Qt5-based client or a Qt6-based client, but not both in the same make run. I haven't tried Qt6 yet.

2021-05-27 12:13 Updated by: cazfi

Reply To jdlh

I haven't tried Qt6 yet.

You're likely to hit #42249 ('moc' not in where we expect it - no idea where it is in Mac Qt-6.1 installation)

2021-05-27 14:15 Updated by: jdlh

OK, I'm going to skip an attempt to use Qt6 with the Qt clients. It's out of scope for this ticket. As long as I can get Qt5 clients in each branch to build, that is enough for me for now.

2021-05-27 16:08 Updated by: jdlh

It looks like branch S3_1 has the same, effective automake scripts as does branch master. The Qt5 clients build successfully on macOS 10.13.6 High Sierra without any patches.

2021-05-27 16:40 Updated by: jdlh

It looks like branch S3_0 requires the same fix as S2_6 to build Qt5 clients successfully on macOS 10.13.6 High Sierra. The patch 128026-Fix-compile-error-for-Qt-clients-on-macOS-FC_QT5_C.patch applies successfully to branch S3_0. With that patch, the Qt5 clients build successfully.

So, I'd ask that this patch be applied to branches S2_6 and S3_0, to allow macOS to build the Qt5 clients.

2021-06-02 22:55 Updated by: cazfi

Just to clarify: Isn't build without this patch working even if you configure with CXXFLAGS="-std=c++11" ? Your choice of words in the comments seems to say so.

2021-06-03 04:41 Updated by: jdlh

I did not try configure with CXXFLAGS="-std=c++11" in my experiments. Apparently Dean did, and it let the configuration succeed. However, I think it is better to have the automake scripts set the -std option, than to expect the person running ./configure to set this in the environment.

2021-06-11 15:15 Updated by: jdlh

Configuring with CXXFLAGS="-std=c++11" was successful for branch S2_6 compiling on macOS 10.13.6 High Sierra. I just tried the experiment. The configure script recognised Qt5 as available, and the freeciv-qt client built successfully.

Even so, I am still in favour of accepting this patch, so that the automake scripts will set that flag, instead of relying on the downstream builder.


You are not logged in. I you are not logged in, your comment will be treated as an anonymous post. » Login