GCC build needs clang?

[elahav]

I'm trying again to build QtWebEngine for QNX. The toolchain file specifies is_clang = false, but at about a third of the build things fail because it is trying to compile something with clang.

A couple of questions:

1. Should a gcc-only build depend on clang?
2. If it does, then where is qtwebengine/src/3rdparty/chromium/third_party/llvm-build, which is supposed to be a part of Chromium?

And just to emphasize - at this point a considerable part of the code has already been built with the right compiler, so it isn't a case of the toolchain not being set up at all.

../../../../../../6.4/qtwebengine/src/3rdparty/chromium/third_party/llvm-build/Release+Asserts/bin/clang++ -MMD -MF clang_x64/obj/base/third_party/double_conversion/double_conversion/double-to-string.o.d -DUSE_UDEV -DUSE_AURA=1 -DUSE_GLIB=1 -DUSE_OZONE=1 -DOFFICIAL_BUILD -DTOOLKIT_QT -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -DNO_UNWIND_TABLES -D_GNU_SOURCE -DCR_CLANG_REVISION=\"llvmorg-15-init-7570-gba4537b2-1\" -DNDEBUG -DNVALGRIND -DDYNAMIC_ANNOTATIONS_ENABLED=0 -Iclang_x64/gen -I../../../../../../6.4/qtwebengine/src/3rdparty/chromium -Wall -Wextra -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -Wimplicit-fallthrough -Wthread-safety -Wno-missing-field-initializers -Wno-unused-parameter -Wloop-analysis -Wno-unneeded-internal-declaration -Wenum-compare-conditional -Wno-psabi -Wno-ignored-pragma-optimize -Wno-unqualified-std-cast-call -Wno-deprecated-non-prototype -Wshadow -fno-delete-null-pointer-checks -fno-ident -fno-strict-aliasing --param=ssp-buffer-size=4 -fstack-protector -Wno-unknown-argument -Wno-unknown-attributes -Wno-unknown-warning-option -Wno-unknown-pragmas -fno-unwind-tables -fno-asynchronous-unwind-tables -fPIC -pthread -fcolor-diagnostics -fmerge-all-constants -m64 -msse3 -no-canonical-prefixes -O2 -fdata-sections -ffunction-sections -fno-unique-section-names -fno-omit-frame-pointer -g0 -fvisibility=hidden -Xclang -add-plugin -Xclang find-bad-constructs -Xclang -plugin-arg-find-bad-constructs -Xclang raw-ptr-template-as-trivial-member -Xclang -plugin-arg-find-bad-constructs -Xclang use-classify-type -Xclang -plugin-arg-find-bad-constructs -Xclang check-ipc -Wheader-hygiene -Wstring-conversion -Wtautological-overlap-compare -Wno-unused-const-variable -Wno-unused-function -Wno-parentheses-equality -Wno-tautological-compare -Wno-thread-safety-attributes -Wno-undefined-bool-conversion -Wno-tautological-undefined-compare -std=c++17 -Wno-trigraphs -fno-aligned-new -fno-exceptions -fno-rtti -fvisibility-inlines-hidden -c ../../../../../../6.4/qtwebengine/src/3rdparty/chromium/base/third_party/double_conversion/double-conversion/double-to-string.cc -o clang_x64/obj/base/third_party/double_conversion/double_conversion/double-to-string.o
/bin/sh: 1: ../../../../../../6.4/qtwebengine/src/3rdparty/chromium/third_party/llvm-build/Release+Asserts/bin/clang++: not found

[elahav]

Debugging a CMake build system wrapping a GN build system wrapping Ninja for a very large project is not that easy. Shocking, right?
Turns out that for the Linux build the clang part is replaced by defining a host toolchain in cmake/Functions.cmake, which is why it does not need the llvm-build directory.
I will try to make the same change for the QNX build, but as I don't understand why parts of the code are built with a different toolchain this is really a shot in the dark.
Do Qt developers monitor this forum? If not, is there a better place to ask this type of questions?

--Elad

[SGaist]

Hi,

For that kind of question you should go to the development mailing list.

[elahav]

@SGaist Thanks, I'll give it a try.