qt513-qtbase @5.13.2_13+openssl: several errors

[thetrial (alabay)]

Does not build though is shown compatible with 10.12.6 Sierra. I’ll add the logfile.

[ryandesign (Ryan Carsten Schmidt)]

Replying to thetrial:

shown compatible with 10.12.6 Sierra

If you mean that ​the qt513-qtbase page on the ports web site shows a successful build status for Sierra, that only reflects the most recent build that was done, which is not necessarily for the version you're trying to build now. We have a huge backlog of builds due to the recent libxml2 and icu updates which we'll still need weeks to work our way through.

The log is a little confusing because evidently this build system outputs results of configure tests to the log. Errors encountered during configuration aren't necessarily errors; they're usually just the configure system detecting the capabilities of your toolchain.

For example, the first error in the configure phase is where it checks if your toolchain has sufficient C++17 support, and it decides that it does not:

Checking for C++17 support...
+ cd /opt/local/var/macports/build/qt513-qtbase-69472076/work/qtbase-everywhere-src-5.13.2/config.tests/c++1z && /opt/local/var/macports/build/qt513-qtbase-69472076/work/qtbase-everywhere-src-5.13.2/bin/qmake "CONFIG -= qt debug_and_release app_bundle lib_bundle" "CONFIG += shared warn_off console single_arch" QMAKE_CXXFLAGS_GNUCXX11=-std=c++17 /opt/local/var/macports/build/qt513-qtbase-69472076/work/qtbase-everywhere-src-5.13.2/config.tests/c++1z
+ cd /opt/local/var/macports/build/qt513-qtbase-69472076/work/qtbase-everywhere-src-5.13.2/config.tests/c++1z && MAKEFLAGS= /usr/bin/make
> /opt/local/bin/clang++-mp-16 -c -pipe -stdlib=libc++ -O2 -std=gnu++1z  -arch x86_64 -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk -mmacosx-version-min=10.12 -w -fPIC  -I. -I/opt/local/var/macports/build/qt513-qtbase-69472076/work/qtbase-everywhere-src-5.13.2/mkspecs/macx-clang -o main.o main.cpp
> main.cpp:14:18: error: 'get<int, int>' is unavailable: introduced in macOS 10.13
>     int i = std::get<int>(v);
>                  ^
> /opt/local/libexec/llvm-16/bin/../include/c++/v1/variant:1560:16: note: 'get<int, int>' has been explicitly marked unavailable here
> constexpr _Tp& get(variant<_Types...>& __v) {
>                ^
> main.cpp:15:10: error: 'visit<(lambda at main.cpp:15:16), std::variant<int> &, void>' is unavailable: introduced in macOS 10.13
>     std::visit([](const auto &) { return 1; }, v);
>          ^
> /opt/local/libexec/llvm-16/bin/../include/c++/v1/variant:1753:26: note: 'visit<(lambda at main.cpp:15:16), std::variant<int> &, void>' has been explicitly marked unavailable here
> constexpr decltype(auto) visit(_Visitor&& __visitor, _Vs&&... __vs) {
>                          ^
> 2 errors generated.
> make: *** [main.o] Error 1
test config.qtbase.tests.c++1z FAILED

The first error during the actual build is:

/opt/local/bin/clang++-mp-16 -c -pipe -stdlib=libc++ -Os -std=c++1y -fapplication-extension  -arch x86_64 -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk -mmacosx-version-min=10.12 -fvisibility=hidden -fvisibility-inlines-hidden -Wall -W -Winconsistent-missing-override -Wobjc-interface-ivars -Wobjc-method-access -Wobjc-multiple-method-names -Werror=unguarded-availability -Werror=unguarded-availability-new -Werror=unsupported-availability-guard -fPIC -DQT_NO_USING_NAMESPACE -DQT_NO_FOREACH -DQT_NO_NARROWING_CONVERSIONS_IN_CONNECT -DQT_BUILD_CORE_LIB -DQT_BUILDING_QT -DQT_NO_CAST_TO_ASCII -DQT_ASCII_CAST_WARNINGS -DQT_MOC_COMPAT -DQT_USE_QSTRINGBUILDER -DQT_DEPRECATED_WARNINGS -DQT_DISABLE_DEPRECATED_BEFORE=0x050000 -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -DQT_NO_DEBUG -I. -Iglobal -I../3rdparty/harfbuzz/src -I../3rdparty/md5 -I../3rdparty/md4 -I../3rdparty/sha3 -I../3rdparty/forkfd -I../3rdparty/tinycbor/src -I../../include -I../../include/QtCore -I../../include/QtCore/5.13.2 -I../../include/QtCore/5.13.2/QtCore -I.moc -I.tracegen -isystem /opt/local/include/glib-2.0 -I/opt/local/lib/glib-2.0/include -I../../mkspecs/macx-clang -o .obj/qcollator.o tools/qcollator.cpp
...
In file included from tools/qcollator.cpp:41:
In file included from tools/qcollator_p.h:59:
In file included from /opt/local/include/unicode/ucol.h:13:
In file included from /opt/local/include/unicode/utypes.h:39:
/opt/local/include/unicode/uversion.h:183:11: warning: nested namespace definition is a C++17 extension; define each namespace separately [-Wc++17-extensions]
namespace U_HEADER_ONLY_NAMESPACE {}
          ^
/opt/local/include/unicode/uversion.h:181:48: note: expanded from macro 'U_HEADER_ONLY_NAMESPACE'
#define U_HEADER_ONLY_NAMESPACE U_ICU_NAMESPACE::U_HEADER_NESTED_NAMESPACE
                                               ^
In file included from tools/qcollator.cpp:41:
In file included from tools/qcollator_p.h:59:
In file included from /opt/local/include/unicode/ucol.h:17:
In file included from /opt/local/include/unicode/unorm.h:25:
In file included from /opt/local/include/unicode/unorm2.h:35:
In file included from /opt/local/include/unicode/uset.h:38:
/opt/local/include/unicode/char16ptr.h:271:55: error: no template named 'is_same_v' in namespace 'std'; did you mean 'is_same'?
template<typename T, typename = std::enable_if_t<std::is_same_v<T, UChar>>>
                                                 ~~~~~^~~~~~~~~
                                                      is_same
/opt/local/libexec/llvm-16/bin/../include/c++/v1/__type_traits/is_same.h:22:29: note: 'is_same' declared here
struct _LIBCPP_TEMPLATE_VIS is_same : _BoolConstant<__is_same(_Tp, _Up)> { };
                            ^

This is may be due to yesterday's icu update. It looks like this icu version requires C++17, so all ports using this version of icu presumably need to require at least C++17 as well, however to compile this file the build has used -std=c++1y, which was the old name of C++14. The previous version of icu also claimed to require C++17, but maybe it required a smaller subset of C++17 that your compiler supports.

qt513-qtbase has been telling MacPorts to require a C++17-capable compiler since 2024, and MacPorts has chosen to use MacPorts clang 16 which according to CompilerSelection is C++17-capable, but qt513-qtbase's test for C++17 capability uses a feature that wasn't added to libc++ until macOS 10.13. Since, as you point out, the build succeeded before, qt513-qtbase's test for C++17 functionality may be overly restrictive and if we override it, it may work. Or, if the build really does need those newer libc++ features when building in C++17 mode, then we may be able to work around this by using the newer MacPorts libc++, for example by using the legacysupport portgroup.

[thetrial (alabay)]

Well, this seems to be an interesting and bigger thing. The mentioned icu went through. I afterwards had to rebuild my tin (which is the only binary I am not taking and buildig via macports due to historical reasons), what also worked.

But, yes but.

I now restore my complete /opt to a state of the day before yesterday – because also my KeePassXC is broken, and I guess this has to do with this broken upgrade chain. I might have to wait until the plug is loosened, but the collateral damage is far too big.

[thetrial (alabay)]

If you mean that ​the qt513-qtbase page on the ports web site shows a successful build status for Sierra, that only reflects the most recent build that was done, which is not necessarily for the version you're trying to build now. We have a huge backlog of builds due to the recent libxml2 and icu updates which we'll still need weeks to work our way through.

Is there a light on the horizon with these icu, libxml2 and qt513-qtbase backlog? Lots of ports depend on especially icu and libxml2. So I don’t upgrade to not break everything again.

[thetrial (alabay)]

I can't keep up anymore … my MP system breaks and breaks because of dependency problem when I try to upgrade. I just can replay backups – and don’t know anymore where the forks are causing problems. Is 10.12.6 lost as OS for MP? There are so many much older platforms that are still supported (or shown as supported), so why is there such a bottleneck occuring now? I don’t find out anymore what to exclude to get rid of these dead ends.

[thetrial (alabay)]

Abandon?

[reneeotten (Renee Otten)]

has duplicate 74012

[thetrial (alabay)]

Well … now the question is: abandon? Or not? Without a fix of exactly this thing so many things will break that MP is not usable anymore für 10.12 when needing programs with qt.

[reneeotten (Renee Otten)]

this is a volunteer project, so people might or might not work on certain issues. You’re free to experiment with suggestions that Ryan already gave (for example, add the “legacysupport” PortGroup) and see if that gets you any further. If it does, that can be added to the macports-ports repository. It looks like nobody is working on this right now; I for one don’t have old OSes to test on so it’s hard to troubleshoot things.

[thetrial (alabay)]

I don’t know how to implement these suggestions. I just can say that the version before the version (I mentioned) worked.