GCC build needs clang?
-
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:
- Should a gcc-only build depend on clang?
- 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
-
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:
- Should a gcc-only build depend on clang?
- 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
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 incmake/Functions.cmake
, which is why it does not need thellvm-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
-
Hi,
For that kind of question you should go to the development mailing list.
-
Hi,
For that kind of question you should go to the development mailing list.