Those are C++ standard library ABI linking errors. The issue is building with LLVM’s headers for std::function, std::exception, etc. means you can’t link cleanly with code built from GCC’s. The two standard libraries are ABI compatible in many places but not everywhere. Qt currently only supports GCC on Linux: Qt for Linux/X11 | Qt 6.6
Practically I believe that this means on Linux you should build with Clang using GCC’s headers instead of LLVM’s. With Clang you do this by passing -stdlib=libstdc++. (LLVM’s library is libc++, GCC’s is libstdc++). I don’t have an opinion on whether it still makes sense to maintain clang builds with Qt6 given this requirement.
THANK YOU @VIRTUALDOG ! This is super helpful. I’ll give it a try, and depending on the outcome/hurdles, I might lean one way or another in terms of maintaining Clang on Linux support.
No problem. It should work fine building this way, I’ve done this on another large project. IMO once you do this the main benefit of building with both compilers is getting two sets of diagnostics/warnings.
It appeared to work, I can launch both scide and sclang from within the new folder.
However, I can’t tell if I’m actually using this new version. The QT about still yields 5.13 ? Is it normal, how can I check if I’m actually using this new version ?
EDIT :
I think this is why I was able to build, clang-14 -v shows that it is using gcc here.
The fact that clang-14 wasn’t natively installed on Ubuntu 22.04LTS might be an indication, regardless of QT6 ? And if the build only work with clang when relying on gcc, does it make sense to keep it ? I don’t know about this.
Ok, no, indeed you can ‘ignore’ my previous message. Though I was cloning the branch, but I was cloning the whole project, because cloning a branch does not make sense. So I compiled ‘develop’ instead .
Still, build succeed. I can confirm with Help > About SuperCollider > Built from branch ‘topic/qt6-12’ [fd468de3f].
EDIT : with QT5, ofc.
EDIT2 :
To prevent building with Qt5 if both are installed :
In /QtCollider/CMakeLists.txt
change find_package(QT NAMES Qt6 Qt5 COMPONENTS Core)
to find_package(QT NAMES Qt6 COMPONENTS Core)
Issue reproduced, so previous comments were wrong.
In any case, I’ve submitted a PR for this. Thanks again @VIRTUALDOG for the pointers and @Dindoleon for building.
Btw @Dindoleon, since you have both qt5 and qt6 installed, could you please checkout the branch topic/qt6-15, and then in a clean build directory run cmake .. and check the output for which Qt version was detected? On this branch, when both qt5 and qt6 are present, I think it should choose qt6. Thanks!
Oh, right I forgot about that project. Yes, it’s a minimal port/adaption which pulls in changes from upstream WebKit, just not supported by Qt Project itself anymore. KDE is the place where a lot of WebKit stuff originated, and they seem to be fully depending on it now after sunsetting KHTML, so it makes sense they are the people primarily maintaining it.
For the future, you can simply delete everything in the build directory, then run cmake .. and the build command. You can checkout any branch before doing that (*), no need to re-download the repository.
Thanks for testing!
You’re missing the -D flag, which needs to precede every argument: cmake -DCMAKE_BUILD_TYPE=Release -DSC_USE_QTWEBENGINE=OFF ..
or cmake -D CMAKE_BUILD_TYPE=Release -D SC_USE_QTWEBENGINE=OFF ..
–
(*) you may need to run git pull to fetch new branches from the remote