Linking issue when building with Clang and Qt6 on Linux

I’ve been working on and off on the Qt6 port and the initial update to Qt6 is (partially?) operational.

However, I encountered an issue when building with Clang under Linux. More information is here: SC fails linking when built with Clang and Qt6 on Linux · Issue #6126 · supercollider/supercollider · GitHub
If you’re able, please take a look, try building it, and report your findings. Thanks!

3 Likes

Thanks for working on this. :slight_smile:

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.

1 Like

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.

1 Like

I just managed to build it. Ubuntu 22.04LTS (Jammy).

Didn’t have clang-14, so :

sudo apt install clang-14
sudo apt install libstdc++-12-dev
sudo apt install libc++-14-dev
sudo apt install libc++abi-14-dev

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.

Did you build from the feature branch? I would just check the output of the build process under verbose to see what directories are included.

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 :sweat: .

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.

Thanks for building @Dindoleon

I thought that find_package(QT NAMES Qt6 Qt5 COMPONENTS Core) would pick up Qt6 first, but apparently not. I’ll change that.

Also, could you confirm that you built it against Qt 5.13? I didn’t expect it to build with Qt <5.15.

I didn’t sorry. I built it against Qt 5.15.3 and my brain inverted both numbers.

I don’t know if it helps.

Forced the use of libstdc++ in /supercollider/CMakeLists.txt

Line 343 :

#############################################
# some preprocessor flags
if (CMAKE_COMPILER_IS_GNUCXX OR CMAKE_COMPILER_IS_CLANG)
	if (SSE)
		set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS}   -msse")
		set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -msse")
		if(NOT APPLE AND NOT CMAKE_COMPILER_IS_CLANG)
			set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -mfpmath=sse")
			set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -mfpmath=sse")
		endif()
	endif()
	if (SSE2)
		set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -msse2")
		set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -msse2")
	endif()
	if (NATIVE)
		set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -march=native")
		set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -march=native")
	endif()

    if(CMAKE_COMPILER_IS_CLANG AND NOT SC_CLANG_USES_LIBSTDCPP)
        # the default
        #set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -stdlib=libc++")
        #set(CMAKE_CXX_LINK_FLAGS "${CMAKE_CXX_LINK_FLAGS} -stdlib=libc++")
    endif()
    
    if(CMAKE_COMPILER_IS_CLANG)
		 set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -stdlib=libstdc++")
		 set(CMAKE_CXX_LINK_FLAGS "${CMAKE_CXX_LINK_FLAGS} -stdlib=libstdc++ -latomic")
    endif()

	if(FORTIFY)
		add_definitions( -D_FORTIFY_SOURCE=2 )
	endif()

	add_definitions(-fvisibility=hidden)
endif()

Here’s build log : Output of forced libstdc++ build SC + Qt6 · GitHub . Sorry, it was translated in French.

After sudo make install, which seems successful, unable to launch scide :

Could not find QtWebEngineProcess
Abandon (core dumped)

For some reasons, couldn’t get SC_USE_QTWEBENGINE=OFF to work. I changed it directly in the QtCollider/CMakeLists.txt. Rebuilt, and installed.

scide is launching, and About QT displays This program uses Qt version 6.2.4. .

How did you try it?

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!

3 Likes

The QtWebKit (deprecated upstream fir years) still works alongside qt6? That’s very good news!

Let’s test a build with most of the GUI using qt6 and see how it’s working.

No… QtWebkit was removed in version 5.6.

1 Like

~2015 is some time, and qtwebkit is standing by itself.

That’s great news)

There is another big project using qtwebkit (KDE), maybe they are doing some work there?

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.

@MarcinP

I wasn’t totally sure how to make a clean build so here’s my process :

mkdir SCSource && cd SCSource/
git clone https://github.com/supercollider/supercollider.git
cd supercollider/
git submodule update --init --recursive
git checkout topic/qt6-15
mkdir build && cd build/
cmake ..

Unfortunately, this still links Qt5 :

-- Found Qt 5.15.3: /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.15.3

For some reasons, couldn’t get SC_USE_QTWEBENGINE=OFF to work.

I tried like this :
cmake -DCMAKE_BUILD_TYPE=Release SC_USE_QTWEBENGINE=OFF ..

But this still tried to use it.

Thanks for checking, @Dindoleon!

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

1 Like

BTW the fix is here, thanks to @VIRTUALDOG 's suggestion.