The feature is not ready for prime-time. Too many linker bugs have been
found, Clang hasn't finished implementing it, and the status of gold and
lld are simply unknown.
Task-number: QTBUG-105002
Pick-to: 6.4
Change-Id: I3859764fed084846bcb0fffd1702fead133a9a96
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
And take the opportunity to remove the "m" in the qmake feature name and
.prf file.
Pick-to: 6.4
Change-Id: I36b24183fbd041179f2ffffd170224ab75cdd968
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Use the full name of LTCG to make it clearer to the user.
As a drive-by, also remove the "Intel" word from the
CET feature's title, according to MSVC & GCC's manual,
they don't contain "Intel" in the feature title either.
Change-Id: I099ba6c5e7470b5699c1ab6b3c4ef2a4bf084580
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The zstd feature might have different values between the host
and target, in which case qmake must tell rcc not to use zstd
when the feature is disabled.
Amends 14546d1816
Fixes: QTBUG-103794
Pick-to: 6.4 6.3 6.2
Change-Id: Ia0378742a50e2a85f59985dea2506d3dda5f28e8
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Use a more detailed description instead.
Also adds the missing part of the GCC parameter.
Amends commit qtbase/42287255d38bf493b5731396b99bc9cd7b1baba4
References:
https://gcc.gnu.org/onlinedocs/gcc-12.1.0/gcc/Instrumentation-Options.html#Instrumentation-Options
Change-Id: I94a22ac7dfa80644e92fe01021f7868dfa02dd69
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Merge all the existing checks into a single one, which is a simple pass
or fail, since all our supported compilers support all the intrinsics up
to Cannon Lake. The two I've recently added (AVX512VBMI2 and VAES)
aren't yet supported everywhere, so they stay.
For some reason, all intrinsics seem to be disabled on Android. It looks
like some support was missing during the CMake port and this was never
again looked at. I'm leaving it be.
As for WASM, discussion with maintainers is that the WASM emulation of
x86 intrinsics is too hit-and-miss. No one is testing the performance,
particularly the person writing such code (me). They also have some
non-obvious selection of what is supported natively and what is
merely emulated. Using the actual WASM intrinsics is preferred, but
someone else's job.
Change-Id: Ib42b3adc93bf4d43bd55fffd16c10d66208e8384
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
The GNU binutils ld linker needed a patch after the tagging of 2.38 to
make the new feature work. Before this patch, the linker will fail to
link when protected visibility symbols are used in the library, so don't
enable the feature unless the linker is recent enough.
GNU binutils gold from that version passes this test.
LLVM lld is unknown (I didn't test), but LLVM was consulted in
developing the feature.
Fixes: QTBUG-103493
Change-Id: Ibcde9b9795ad42ac9978fffd16f1c80ca20953ff
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Do build zlib as static 3rdparty library. This makes it easier to
disable warnings.
Pick-to: 6.3
Change-Id: I1db331b671b64e68d81c56b0df337983c3bbe7fa
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Instead of complicating the condition even more, just use the value of
QT_WILL_INSTALL which is determined in QtSetup before configure.cmake
is loaded.
The AUTODETECT part is needed to ensure that
-developer-build
implies -no-prefix.
The CONDITION part is needed so that
-extprefix /tmp/sysroot -no-prefix
correctly errors out saying that this can't be a non-prefix build,
unless
-extprefix ${qtbase_build_dir} -no-prefix
is passed.
Pick-to: 6.2 6.3
Change-Id: Ie4f5a91281bf2fbe1bd0744de05d57f43fe992e7
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
This fixes the "Could not find feature c++2b." error when building a Qt
module with qmake.
The feature is OFF by default for now.
This amends commit b5ed3cb7ba.
Pick-to: 6.2 6.3
Change-Id: Ibabe3ce29275699e66ab1f32d19d583d6bcede9e
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The -mno-direct-extern-access tells the compiler and linker that
references to symbols outside this ELF module mustn't be direct and must
instead always go through the GOT or PLT (the PLT can additionally be
disabled with -fno-plt). The ELF protected visibility tells the compiler
and linker that this symbol is present in the dynamic symbol table as an
export, but it cannot be interposed by another ELF module.
This option is required for user code to link properly to Qt, otherwise
they will get linker errors (assuming GNU binutils >= 2.39) or runtime
failures (glibc >= 2.35). Both versions of glibc and binutils are older
than GCC 12, so it's a safe assumption they are in use and downgrading
the toolchain or libc is not supported. Adding this option to the
compilation is assured for CMake and qmake-based projects.
For example, all accessess to QCoreApplication::self in QtCore, after
this change and with GCC 12 are relocation-free and direct:
000000000013ebf0 <QCoreApplicationPrivate::checkInstance(char const*)>:
13ebf0: cmpq $0x0,0x4f73d0(%rip) # 635fc8 <QCoreApplication::self>
13ebf8: setne %al
13ebfb: je a90fe <QCoreApplicationPrivate::checkInstance(char const*) [clone .cold]>
13ec01: ret
Meanwhile, accesses to the same variable in other modules are indirect
via the GOT:
66650: mov 0x876e1(%rip),%rax # edd38 <QCoreApplication::self@Qt_6>
66657: cmpq $0x0,(%rax)
This replaces the -Bsymbolic and -Bsymbolic-functions (broken)
functionality that Qt has been using or attempting to use since ~2006.
See https://gitlab.com/x86-psABIs/x86-64-ABI/-/issues/8#note_606975128
Change-Id: Iad4b0a3e5c06570b9f5f571b26ed564aa0811e47
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
We have VAES code in qhash.cpp that isn't getting compiled right now.
Change-Id: Ibf4acec0f166495998f7fffd16d6961261dec361
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
And the target ZSTD::ZSTD to WrapZSTD::WrapZSTD.
This should allow building Qt with the
-DCMAKE_FIND_PACKAGE_PREFER_CONFIG=ON set.
Pick-to: 6.2 6.3
Fixes: QTBUG-100537
Change-Id: I748601e4ad6f518323bf1034d6fc1de582c815e1
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Introduce a new -no-prefix option that can be used to build Qt without
having to install it.
Currently, -no-prefix is already implied by -developer-build, but
-developer-build also implies -warnings-are-errors and
-feature-private-tests, which not everyone might want to use.
Some Qt builders likely use -developer-build for the no-prefix
behavior, hence we introduce a standalone -no-prefix option to offer
a nicer user experience without -Werror and friends.
Previously it was possible to achieve the same by specifying
-prefix $PWD, but that relies on $PWD expanding property in the used
shell.
The new -no-prefix doesn't depend on the type of the shell and
is shorter to type.
Internally this gets passed by configure as -DINPUT_no_prefix=yes to
CMake, and transformed into a -DQT_FEATURE_no_prefix=ON feature.
The feature also gets automatically auto-detected to ON if
developer-build is set, -prefix is either unset or $PWD.
CMake code should still query QT_WILL_INSTALL to decide whether
files need to be installed or not.
As a drive-by, we now also export QT_FEATURE_developer_build to
be available for querying during configuration of other repos
(previously it was only possible to query FEATURE_developer_build).
Pick-to: 6.2 6.3
Change-Id: Iaa6c8d8ae2b736282e9949d2a5d7f412e290a253
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
All[*] compilers support it, always. The last to not support it was GCC
4.8, which we don't support in Qt 6.
[*] Anecdotally, clang-cl doesn't but clang-cl isn't supported and that
would be an upstream problem: clang-cl developers must find a solution
that either matches Clang or cl.exe.
Change-Id: I54f205f6b7314351b078fffd16d0a5ed5b7afae5
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
The mold linker is a new linker for Linux that provides faster link
times compared to BFD ld, ld.gold and lld.
It can be found at https://github.com/rui314/mold
To build Qt with mold, ensure that the binary in your PATH and then
configure Qt with with either
cmake /path/to/qtbase -DINPUT_linker=mold
or
/path/to/qtbase/configure --linker mold
The change was tested with gcc 9, clang 10, clang 12, mold
1.0.0. Only qtbase and qtdeclarative (and dependencies) were tested.
Pick-to: 6.2 6.3
Task-number: QTBUG-99270
Change-Id: I2e64a1f4257c37ff5b64a9326e548b9b46e07c80
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Previously we passed flags like -ld-fuse=lld only to compile
calls, but not to the link call of a compile test project.
Make sure to pass it to the link call instead by using
check_cxx_source_compiles + CMAKE_REQUIRED_LINK_OPTIONS
instead of
check_cxx_compiler_flag.
Note the flag that is passed is still via passed via the
compiler launcher and not directly to the linker.
Remove duplicate flag handling code.
Pick-to: 6.2 6.3
Change-Id: I1bf90573904a9df83240b6debfee3cc9e425c6bb
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Emscripten only supports
SSE1, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, and 128-bit AVX instruction
sets at this time.
https://emscripten.org/docs/porting/simd.html
Browsers might need to enable simd support in the advanced
configurations
about: config or chrome:flags
Enable by configuring Qt with -sse2
Pick-to: 6.2
Fixes: QTBUG-63924
Change-Id: Ifeafae20e199dee0d19689802ad20fd0bd424ca7
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
Whether Qt is built with PrintSupport is now listed under "Qt modules
and options" in the configure summary.
Pick-to: 6.2
Task-number: QTBUG-88535
Change-Id: Id367c9594482b0764da679c3cbdee2f5108201ef
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
We're passing -Oz for release builds, but that's not a flag the linker
understands when -ltcg is enabled. The build fails with:
ld.gold: fatal error: Optimization level must be between 0 and 3
Fix this by using -O2, which -Oz is based on, and -O3 for the "full
optimization" that is used for core and gui.
Pick-to: 6.2
Fixes: QTBUG-89472
Change-Id: Ie1a86888baefce5ca97026e7d635f10d2819f9f4
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The -coverage argument merely added compiler flags for the Qt build. It
was never properly ported to the CMake build, and it doesn't seem
feasible to have configure arguments for every possible compiler option.
The same can be achieved by passing the needed compiler option to CMake,
for example: CMAKE_CXX_FLAGS=-fsanitize-coverage=trace-pc-guard
Pick-to: 6.2
Fixes: QTBUG-86227
Change-Id: Ieef9acaedc0a839f9fb35b4403395eea28643864
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
qt_config_linker_supports() repeated the conditions of all use_*_linker
features, because the features are not evaluated yet when this function
is called, and the function needs to know what linker is used to build Qt.
Move the required tests and features before any
qt_config_linker_supports() call and evaluate the use_*_linker features
early.
Change-Id: I306f032356682a0e82e4d7c4234e5bbc820ab143
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This configure test always failed, and its result was never used.
Pick-to: 6.2
Change-Id: I5112464b247efb5327ef5c23c96ef27168c11afc
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Consumers can now check the "debug" feature to determine whether Qt was
built in the "Debug" configuration.
Pick-to: 6.2 6.1
Change-Id: I225125d38ded508e9792a730ce421b33bceacddf
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Adds runtime CPU detection for Windows and macOS, and switches feature
detection of AES to runtime like for x86,
So far only on ARM64, since gcc doesn't do function versioning on ARM32,
but clang can, so it could be added later.
Change-Id: Ibe5d60f48cdae3e366a8ecd6263534ba2b09b131
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
MSVC does not have pthreads.
"QT_FEATURE_thread" should mean "Enable thread support".
And I think this note is only meaningful for WASM. For other platforms,
thread support should be enabled by default.
amends 4972fdb350
Change-Id: I5a4fc05219c9b2ff9c6e54fd444b4b94230727bb
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
And adjust configure.json files that were stale
Amends d385158d52
Change-Id: I851838a12c3773a6e8119ebc7f1de941ae7fe224
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Add SOLARIS cmake platform definition.
Add settings for QT_DEFAULT_MKSPEC so that qplatformdefs.h can be found.
Solaris has its gssapi symbols in libgss.
Solaris supports @ORIGIN.
Solaris ld does not support --dynamic-list needed for reduce relocations.
Make solaris fail the reduce relocation test.
getauxval is specific to GNU libc and some other libc implementations on
Linux but sys/auxv.h is not. The bootstrap uses sys/aux.h as the only
indication for getauxval. This breaks builds on Solaris, so only make
sys/auxv.h an indicator for getauxval on linux or glibc based systems.
Solaris uses X11 so add it to the X11_SUPPORTED list.
Solaris network libraries for sockets etc are in socket and nsl.
ifreq does not have a member ifr_ifindex on Solaris, it uses
ifr_index. Add test to check if ifr_index is a member of ifreq.
The first struct in the in_addr union on solaris is defined as four
uint8_t, therefore four arguments are needed for its initializer list.
Change-Id: Ieed4c1bbac8559a7ae1db9c4e1e91f609f150270
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Xcode allows building a project targeting either the device or
simulator sysroot in one single build dir, but for the sysroot
switching to work there should be no linker or compiler flags
referencing absolute paths of a specific sysroot.
During CMake configuration of a project targeting iOS, all found
system libraries will be within one single sysroot, either the device
one or the simulator one, whichever one was passed to
CMAKE_OSX_SYSROOT. CMake will then generate the Xcode project
and pass those absolute paths, which makes sysroot switching within
Xcode not work.
To avoid that, the CMake documentation recommends passing linker and
framework flags of the form '-lfoo' and '-framework bar' instead of
absolute paths. Xcode then takes care of setting the correct framework
search path.
Zlib is one of the libraries found in the iOS sysroot and thus passed
as absolute path.
To avoid that, create a new FindWrapZLIB find script. The target it
creates will pass the absolute path to the library on non Apple
platforms and an -lz linker flag on Apple platforms (macOS and iOS).
To avoid issues with target global promotion when system PNG package
is found, ensure that a found ZLIB::ZLIB target is promoted to global
manually in src/gui/configure.cmake.
Pick-to: 6.1
Change-Id: I8bd8649be4f680a331ad51925f27cb9d13ac5e5f
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
CMake 3.18 introduced the file(ARCHIVE_CREATE) API that we use with
COMPRESSION Zstd for compressing corelib's mimedatabase.
It's possible to build CMake without proper zstd support, and we have
encountered such builds in the wild where the file(ARCHIVE_CREATE) call
crashes.
Add a configure test to determine whether CMake properly supports the
Zstd compression method.
Fixes: QTBUG-89108
Change-Id: I37e389c878845162b6f18457984d4f73a265b604
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
We need to feed gn with linker info for qtwebengine build.
Change-Id: I4bd96af8bb8a1927e4c03e5c5d4ade10a0876eb1
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Use the same approach we use for iOS, which is to set multiple
CMAKE_OSX_ARCHITECTURES values and let the clang front end
deal with lipo-ing the final libraries.
For now, Qt can be configured to build universal macOS libraries by
passing 2 architectures to CMake, either via:
-DCMAKE_OSX_ARCHITECTURES="x86_64;arm64"
or
-DCMAKE_OSX_ARCHITECTURES="arm64;x86_64"
Currently we recommend specifying the intel x86_64 arch as the first
one, to get an intel slice configuration that is comparable to a
non-universal intel build.
Specifying the arm64 slice first could pessimize optimizations and
reduce the feature set for the intel slice due to the limitation
that we run configure tests only once.
The first specified architecture is the one used to do all the
configure tests.
It 'mostly' defines the common feature set of both architecture
slices, with the excepion of some special handling for sse2 and
neon instructions.
In the future we might want to run at least the Qt architecture config
test for all specified architectures, so that we can extract all the
supported sub-arches and instruction sets in a reliable way.
For now, we use the same sse2 hack as for iOS simulator_and_device
builds, otherwise QtGui fails to link due to missing
qt_memfill32_sse2 and other symbols.
The hack is somewhat augmented to ensure that reconfiguration
still succeeds (same issue happened with iOS). Previously the sse2
feature condition was broken due to force setting the feature
to be ON. Now the condition also checks for a special
QT_FORCE_FEATURE_sse2 variable which we set internally.
Note that we shouldn't build for arm64e, because the binaries
get killed when running on AS with the following message:
kernel: exec_mach_imgact: not running binary built against
preview arm64e ABI.
Aslo, by default, we disable the arm64 slice for qt sql plugins,
mostly because the CI provisioned sql libraries that we depend on only
contain x86_64 slices, and trying to build the sql plugins for both
slices will fail with linker errors.
This behavior can be disabled for all targets marked by
qt_internal_force_macos_intel_arch, by setting the
QT_FORCE_MACOS_ALL_ARCHES CMake option to ON.
To disble it per-target one can set
QT_FORCE_MACOS_ALL_ARCHES_${target} to ON.
Task-number: QTBUG-85447
Change-Id: Iccb5dfcc1a21a8a8292bd3817df0ea46c3445f75
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
A few configure defines get changed:
QMAKE_WASM_PTHREAD_POOL_SIZE is now QT_WASM_PTHREAD_POOL_SIZE
QMAKE_WASM_TOTAL_MEMORY is now QT_WASM_INITIAL_MEMORY
QMAKE_WASM_SOURCE_MAP_BASE is now QT_WASM_SOURCE_MAP_BASE
device-option EMSCRIPTEN_ASYNCIFY=1 is QT_EMSCRIPTEN_ASYNCIFY=1
To create source maps for debugging. use
device-option QT_WASM_SOURCE_MAP=1
Task-number: QTBUG-78647
Change-Id: If9f30cd7fb408c386d6d69b5f7b1beecf1ab44b5
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Needed for QT_FEATURE_foo checks in repos other than qtbase when
building SIMD specific files (e.g. qtimageformats).
Task-number: QTBUG-85447
Change-Id: Ibd2200fe24cecbb0b2a092f645ca622baf738601
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Setting a lib infix is not supported with framework builds due to the
nature framework of include resolution: includes like <QtCore/qstring.h>
won't work if the framework is named QtCoreInfix.
The combination framework build and lib infix was agreed on to be out of
scope in the comments of QTBUG-35604.
Pick-to: 6.1
Change-Id: Ib7c6983f2f64ea1a7cfcd56657d31eeab3f55fe3
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
The generated code contained many repeated blank lines.
Most main()s were preceded by one, but not all.
Only include blank lines for actual empty entries in lists, where
configure.json specified them, plus one before main if anything else
precedes it.
Change-Id: I6e6c34940e08712a1aa848a3c9ad1b0fb5806d77
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
The main(void) signature obviates the need for unused parameters and
has existed since (at least) C89; so use that instead of the
old-fashioned argc/argv arguments we don't use in any of these tests.
Change-Id: Ibfe850a1fce378673c9781011475ea623fd75ad4
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
At least, running util/cmake/configurejson2cmake.py changes these lines.
Adding them has provoked the script to add a .prev_configure.cmake file.
Change-Id: Idc123d1dee2ce51cd640c090c7910ecc1f0fc5a4
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Keep the c++2a feature, but make it an alias for compatibility
purposes.
Pick-to: 6.1
Change-Id: I6f153109be84659806f1b7a57a88a187875166d8
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Introduce the 'printsupport' feature to control whether the PrintSupport
module is built.
[ChangeLog][QtPrintSupport] Building of QtPrintSupport can be disabled
by passing -no-feature-printsupport to configure.
Fixes: QTBUG-90778
Change-Id: I8a9a4b7f8dd8f39a81565c8eb14ce1ae0839267d
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Nodir Temirkhodjaev <nodir.temir@gmail.com>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
