TEST_x86intrin_OUTPUT is not set anymore since we lazily evaluate
compile tests after 605913f9d7a60461939c1a8fb8dac05054cade2d .
Use the new qt_configure_add_report_entry
COMPILE_TESTS_TO_SHOW_ON_ERROR option to dump the test values in case
of an error.
Amends 9e9099865a0881ac5bb6035237e0a0c86962c45f
Pick-to: 6.8 6.9 6.10
Task-number: QTBUG-122596
Change-Id: I48d1c57145ad5d9418631025927581c4eb5ec93c
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
...but only if the feature has been turned on explicitly.
Fixes: QTBUG-135026
Change-Id: I4125d26b00ec14511ada5c973ffe7616a24e673c
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Whether precompiled headers are used during the Qt build is controlled
by the CMake variable BUILD_WITH_PCH and the qt_auto_detect_pch
function.
The precompiled_header feature wasn't actually used. Remove it and the
corresponding configure test.
Fixes: QTBUG-134425
Change-Id: I9b2ff9cbcf4888899b6a39d22d260388a9375c5c
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
On macOS, Core has plugins that link against CorePrivate. In a
non-prefix build, user projects failed on find_package(Qt6 REQUIRED
COMPONENTS Core), because CorePrivate is required for these plugins in
a non-prefix build, but it's not automatically pulled in.
This is only an issue for CMake < 3.26, because these older CMake
versions lack the BUILD_LOCAL_INTERFACE generator expression.
Fix this by pulling in the private modules for non-prefix builds when
using CMake < 3.26. Also, issue a warning in this situation.
Fixes: QTBUG-134407
Change-Id: I7f182c9518686390e657663b452cad8101d870a2
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Create a function `_qt_internal_set_source_file_generated` that sets the
source file property `GENERATED` along with Qt relevant properties:
- `SKIP_LINTING` if CMake>=3.27 and `QT_FEATURE_lint_generated_code`
Task-number: QTBUG-125077
Pick-to: 6.9
Change-Id: I0ef5f7901f502366aaf2d020554c72e4845101b6
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
We do not support printing and sql, so best not to build and
shipping them.
Change-Id: Ibc929b127fd8416aa3d3b784a6ed0c2ce86db80d
Reviewed-by: Even Oscar Andersen <even.oscar.andersen@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Make this a proper Qt configure feature:
-feature-wasm-jspi
Using the JSPI name matches the updated Emscripten naming
as well, which as moved from "asyncify 2".
Task-number: QTBUG-129748
Change-Id: Idfc372f831d1db5c79109c97a00e30e58713f9f6
Reviewed-by: Jøger Hansegård <joger.hansegard@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Piotr Wierciński <piotr.wiercinski@qt.io>
This will produce an error when configuring Qt with Emscripten
version less than what is recommended version.
It will produce only a warning when configuring using
Emscripten version greater than recommended.
Change-Id: I62016394e8e52657a5e1d78c4288866e83af2d28
Reviewed-by: Piotr Wierciński <piotr.wiercinski@qt.io>
Reviewed-by: Even Oscar Andersen <even.oscar.andersen@qt.io>
Now that we have a separate feature, we can fix QTBUG-99063 by disabling
the doc_snippets feature globally.
Task-number: QTBUG-99063
Change-Id: I77ba875633ed89fdd8b8481ea0fddc7e91cbb9ca
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
We'd like to compile-test doc_snippets on some configurations. So far,
we enable this by checking the private_tests feature, that is in turn
enabled by default by developer_build.
Let's rather have a separate doc_snippets feature, as we might turn
this on and off independently from private tests. In fact, private API
shouldn't be used by any of the snippets.
Change-Id: Icba8f6af610d7951e65783d8b1700be57584cc4d
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Don't disable the separate_debug_info test but mark it as successful on
Apple platforms and MSVC. This enables us to simplify the condition of
the separate_debug_info feature. Also, we fix the error on MSVC when
passing -separate-debug-info to configure.
Fixes: QTBUG-108015
Pick-to: 6.8
Change-Id: Ifb1f18b2be8a0b5693a3448c1b8198f773f94ffb
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Seeing just "Enable thread support" sounds like an imperative, which
is strange to see because it is only shown if thread support was
explicitly enabled.
Reword it slightly.
Pick-to: 6.8
Change-Id: I37596118dfc66204aa3ff81397caa818a5a91e66
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Lorn Potter <lorn.potter@qt.io>
Adds loongarch simd extension(LSX LASX) configure test and
-feature-lsx and -feature-lasx configure options.
Add detection of LSX and LASX at run-time in qsimd.cpp.
Change-Id: I63eab2f4f45c306b672a89b376e0cbc01da0df83
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Add a feature to build QtGuiTest namespace.
Enabled by default, in order to provide access to Squish UI tests.
Fixes: QTBUG-125594
Change-Id: I0188dceb0d966c1837263756ffe7337b69f935f3
Reviewed-by: Stefan Gehn <stefan.gehn@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
We had no routines for checking compiler support instead only compiler
currently enabled.
Change-Id: I5543e4cff2b0bab494e11abf257061147baaf0d7
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
We had a mismatch of the naming of the Qt and compiler defines. Matched
the qt defines to the compiler define, and added detection support for
MSVC (ARM64).
Pick-to: 6.8
Change-Id: I9abfbe8a96bc8c800e86dac3ab9a7abf9c1f7f9f
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
We don't test for this anywhere in qtbase except for the qmake check
(and qmake doesn't use alloca() anywhere). There are a couple of uses of
alloca() itself in qtbase, but they are all in platform-specific code
(android and qnx platform plugins) or third-party content (sqlite and
imgui).
The uses of this alloca() test in qtdeclarative have been removed too
(it still uses alloca() but has local tests).
Change-Id: If3345151ddf84c43a4f1fffd17d1f1519f5d3e39
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
The feature allows enabling/disabling exceptions for the Qt builds.
The feature is disabled by default.
This commit reworks the way the exception flags are set for Qt targets.
Instead of setting them per-target, flags now are set for the
QtPlatformCommonInternal target, which transitively propagates the flag
to other Qt targets. To disable/enable exception flags the newly
introduced property _qt_internal_use_exceptions can be used. The flags
enabling/disabling now can happen any time, but not only at target
creation time. The property has 3 states: TRUE, FALSE, DEFAULT(or
empty). If the property is not set or is set to DEFAULT, the exceptions
feature value is used to set the required exceptions flags. Otherwise
the flags are set according to the property value.
The logic of EXCEPTION argument of the various qt_internal_add_
functions was also updated. If the argument is not provided, the
_qt_internal_use_exceptions property value is set to DEFAULT, which
gives the control on the exception flags to the feature. If the
argument is provided, the exceptions are enabled by setting the
_qt_internal_use_exceptions property to TRUE.
Task-number: QTBUG-118901
Change-Id: I83e3bf52d48a3d16977cce849c9b0765c34f1f21
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The way that Qt checks if C++20 is supported by the platform does not
work properly on VxWorks.
Their toolchain accepts the C++20 switch, because they use clang with a
wrapper around it, that (for the time being) does not reject it.
The compiler itself claims that it does support C++20.
The problem is that the standard library available on VxWorks only
supports C++17.
This leads to Qt falsely believing that C++20 is supported.
This is being discussed as a defect in support case 00152044.
Prevent weird compilation errors by failing early if the user passes
-feature-c++20 to the configure call.
Task-number: QTBUG-115777
Pick-to: 6.7 6.8
Change-Id: Ica6686428b01a0638117f853586313be63e5fe99
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
GCC generates broken code with that option enabled, see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115527 .
For simplicity I'm not building a comprehensive set of GCC versions
which do have the fix applied; I'll just exclude old ones.
Change-Id: Ia2f128cac633f8d72d5aedc5efe4e64e1c40c51b
Pick-to: 6.8
Fixes: QTBUG-127507
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Add a check for localtime_r/localtime_s to avoid the usage of a sqlite
mutex when a time needs to be converted.
Pick-to: 6.8
Change-Id: I536497da1938131298c1198db85dab74d6157e35
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
As part of fee15182949e88682131399c50b679be83a75385 we enabled framework
debug builds, which left us with an inconsistent library naming. The
framework libraries are always unsuffixed, e.g. QtGui.framework/QtGui,
while we were adding _debug suffixes to the plugins and static libs.
This was confusing macdeployqt, as it uses simple string matching logic
for "_debug_" to detect that a Qt build is a debug build, and since
the framework library didn't have a suffix it then failed to deploy
the suffixed plugins.
We now follow the requirement from the framework naming and skip the
suffixing for all libraries in this configuration.
Pick-to: 6.8
Change-Id: I982253fc46c65aa3fab52f8658f62ef63cdac49f
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
[ChangeLog][CMake] Added the configure feature 'force-system-libs'.
Enabling this feature enables every 'system-foolib' feature, and the
system-provided 3rdparty library foo will be used. If the library is not
found, an error is yielded. Also added the analogous
'force-bundled-libs' feature that enforces the usage of bundled 3rdparty
libs.
[ChangeLog][CMake] The configure script gained the options
-force-system-libs and -force-bundled-libs that control the same-named
configure features.
Since we now need a way to mark a feature as "controlling the usage of a
system 3rdparty library", we added the SYSTEM_LIBRARY feature to the
qt_feature command. Patches that add this argument to qt_feature calls
in other repositories follow.
Fixes: QTBUG-96910
Change-Id: I5c411409ea5f3f6425b6bed6fa00d10eddbc366c
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
In non-MSVC configurations this feature is meaningless.
Restrict it to MSVC.
Pick-to: 6.8
Change-Id: Ib5111e8adf49a862d8ca0f191837d8c28aab6890
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Promote all internal zstd targets if they were found by WrapZSTD to
global using PROVIDED_TARGETS mechanism.
Amends 7d9d1220f367d9275dfaa7ce12e89b0a9f4c1978
Task-numer: QTBUG-119469
Change-Id: I15ec484304f7bf2b3ee2a533d2badb3bb7797863
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This feature allows to explicitly disable the version tagging for Qt
libraries and have the precise feature-based guarding in C++ code.
Task-number: QTBUG-124346
Change-Id: If109adb2f6a998c58825a2449cfb936ea278b2ad
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This way we can identify whether the type is float or double or
something else in the preprocessor. This is helpful for identifying the
primitive types available to QML.
Change-Id: I635f01cb888b9a6a5b35c3f1cbd6e66ff8a65beb
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Static frameworks are now a supported by Apple, so we switch the default
for all Apple platforms, including Qt for iOS and visionOS.
https://developer.apple.com/documentation/xcode/creating-a-static-framework
This allows us to bundle resources with our libraries, such as the
privacy manifest.
Xcode 15 and later will ensure that the linked and embedded framework
is not copied into the application bundle, as it's already linked into
the app as a static library.
Change-Id: Iaf64e7df2d6969d9562fb31ba65f05767e14506e
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Qt already runs on Vision Pro as "Designed for iPad", using Qt
for iOS. This change enables building Qt for visionOS directly,
which opens the door to visionOS specific APIs and use-cases
such as volumes and immersive spaces.
The platform removes some APIs we depend on, notably UIScreen,
so some code paths have been disabled or mocked to get something
up and running.
As our current window management approach on UIKit platforms
depends on UIWindow and UIScreen there is currently no way to
bring up QWindows. This will improve once we refactor our
window management to use window scenes.
To configure for visionOS, pass -platform macx-visionos-clang,
and optionally add -sdk xrsimulator to build for the simulator.
Change-Id: I4eda55fc3fd06e12d30a188928487cf68940ee07
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
'headersclean' shoudn't be a feature. The respective flag should behave
like command-line switch that affects the only repo that it was passed
for. This also avoids propagating of the headersclean feature between
the different repos when qtbase was built with the headerclean enabled.
Fixes: QTBUG-121722
Change-Id: I304cbc980b06030513c015a2016678a6a0965fed
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
45fd36f1480a6229879a4e59236ffa1d1d22dfbf triggers internal
compiler errors in MSVC2019 when configuring Qt with -c++std c++20. Bail
out early when trying to configure a C++20 build with MSVC 2019.
Change-Id: Ic0a49c43e08d3d46221c5c060c0b92628898e26e
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
We do not know yet why it fails exactly to link, and what a proper fix
would be. For now, unconditionally disable it so that we can get
submodule updates in again.
Task-number: QTBUG-123715
Change-Id: I832cc8801c7fcb4b0a755aa4ff0bc65d15bf8230
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This commit enables hardened-specific checks and codegen, inspired by
GCC 14's -fhardened command line switch and LLVM/libc++'s hardened
modes.
We enable (depending on compiler capabilities):
* -ftrivial-auto-var-init=pattern;
* -fstack-protector-strong;
* -fstack-clash-protection;
* -fcf-protection=full or /CETCOMPAT;
* -D_FORTIFY_SOURCE=3 or 2 on Glibc, depending on the Glibc version,
provided that some optimization level is enabled (release build or
optimized debug build);
* on libstdc++, -D_GLIBCXX_ASSERTIONS;
* on libc++, -D_LIBCPP_HARDENING_MODE set to
_LIBCPP_HARDENING_MODE_EXTENSIVE in debug and to
_LIBCPP_HARDENING_MODE_FAST in release (_DEBUG is too slow);
* -Wl,-z,relro,-z,now.
This aligns us 100% with -fhardened (we already pass -fPIE and -pie
anyhow). Some Linux distributions already ship GCC/Clang with some of
these options enabled by default.
The check for Intel CET has been amended to always test if the compiler
supports the corresponding flag; and, if so, enable the feature. Before,
it was behind a configure option and the test only checked if the
compiler had CET support automatically active (the test didn't pass
-fcf-protection to the compiler).
The check for -fstack-protector-strong has been made general (rather
than QNX-specific). We don't support QNX < 7 anyhow.
Finally, the qt_config_linker_supports_flag_test test has been
amended to also support MSVC.
All of the hardening options are enabled by default.
[ChangeLog][Build System] Qt builds by default in "hardened mode",
meaning that a series of security-related compiler options are
automatically enabled. In the unlikely case in which these options
constitute an unacceptable performance hit, it is possible to disable
individual hardening options when configuring Qt.
Change-Id: I2c026b0438010ad10d5e7b1136fedf4ae3af8822
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The SDK is relevant for all Apple systems, including macOS, iOS, tvOS,
watchOS, and visionOS.
We still pick up -DQT_UIKIT_SDK for iOS for compatibility.
[ChangeLog][CMake] The -sdk configure argument now maps
to the QT_APPLE_SDK CMake variable. QT_UIKIT_SDK is still
supported for iOS builds for compatibility.
Change-Id: I983a2f23c2414eb73cd35bb83738088defb45cbd
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
When the intrinsics test failed, we never showed the failing build
output due to two reasons:
- TEST_x86intrin_OUTPUT was empty
- bracket arguments don't do variable expansion
Use the newly introduced feature in qt_config_compile_test to get
the output.
Replace the usage of a bracket argument with a concatenation of
regular strings.
Amends db342f42a4b00f858cb43328c9fdaff5fe2b5788
Pick-to: 6.5 6.6 6.7
Task-number: QTBUG-122596
Change-Id: I7cdef9a145ac64c8fced8add4879fa19b8bcd19d
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Frameworks on Apple systems have traditionally been wrappers around
dynamic libraries (with headers and other resources bundled alongside
the library), but nowadays it's fully supported to have frameworks
with static libraries inside them.
Enabling this allows us to build Qt for iOS statically, but as
frameworks, which allows us to include privacy manifests for the
Qt libraries in the frameworks.
At build time Xcode will link the static library into the application,
as normal, so nothing changes there. If the user then chooses to
embed the Qt frameworks via the Xcode UI, the build system will
not copy the static libraries inside the frameworks, but will
copy the privacy manifest and other resources, which in turn
allows Xcode to generate a privacy report for the application
as a whole.
Task-number: QTBUG-114319
Change-Id: Ibc8c70a97d288e27811eaedd242613fa206617e5
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Many modern features of the Apple application build and packaging pipeline
require that the libraries are shipped as frameworks, so that they can
embed resources (privacy manifest e.g.), be signed, and have their own
Info.plist.
We build and ship our binary packages already as frameworks, and it has
been the default for release builds for a while. Let's enable it for
debug builds as well, so that developers are testing what we ship
(debug is the default for -developer-build).
The error about debug builds not being compatible with frameworks has
been removed, as this works fine in practice. With CMake we don't add
a '_debug' suffix to the libraries unconditionally for debug builds.
Change-Id: I373b982affd8cf70b215d4a92225467ff1037fe8
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
and an older CMake 3.22, which is shipped by default on Ubuntu 22.04.
If for some reason there's a static openssl library lying around in
the default sysroot (or any ssl search path), like in
/usr/lib/libssl.a,
then CMake's _OpenSSL_test_and_find_dependencies
will try to find_package(Threads) because it assumes it has a
dependency on the Threads package.
Because we do qt_find_package(WrapOpenSSLHeaders) in
qtbase/configure.cmake
and we do qt_find_package(Threads) in
src/corelib/CMakeLists.txt,
we would create the Threads target in the root directory scope, and
then try to promote it to global in the corelib subdirectory,
which fails with
CMake Error at qtbase/cmake/QtPublicTargetHelpers.cmake:260
(set_property):
Attempt to promote imported target "Threads::Threads" to global scope
(by setting IMPORTED_GLOBAL) which is not built in this directory.
Call Stack (most recent call first):
qtbase/cmake/QtFindPackageHelpers.cmake:211
(__qt_internal_promote_target_to_global)
qtbase/src/corelib/CMakeLists.txt:4 (qt_find_package)
Newer versions of CMake's FindOpenSSL actually try to determine if
the Threads package is really needed.
To avoid the issue entirely, just look up Threads before we look up
the OpenSSL package.
Pick-to: 6.5 6.6 6.7
Change-Id: Ia3cde93e26ba004f64105a5b457098e1b9870885
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
This reverts commit d201c0a2184881a226bce76528047707e9062856.
Reason for revert: QNX have support only for OpenSSL1.1.
QNX will start supporting OpenSSL3 with upcoming QNX8.0 but as long as we want to support QNX7.1 (and even QNX7.0) removing OpenSSL1.1 support from Qt is not an option.
Change-Id: Ia2083eda318779968eb6ee84fff2f56ebe3dadf7
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
OpenSSL 1.1 reached EOL last September [1]. We will only support
OpenSSL 3.
Cherry-picking aggressively, as there's no purpose at keeping maintained
Qt versions work with an unmaintained library given the security
implications.
[1] https://www.openssl.org/blog/blog/2023/09/11/eol-111/
[ChangeLog][QtNetwork][SSL] Support for OpenSSL 1.1 has been dropped. Qt
now only supports OpenSSL 3.
Change-Id: I51a231a9ca17804739acbd2f22c478d2a8ff9b3b
Fixes: QTBUG-119330
Pick-to: 6.6 6.5 6.2 5.15
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
dbus is not supported on VxWorks
Task-number: QTBUG-115777
Change-Id: Ia594ddca819ade2d5004dde3da59717e4735b823
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
