'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>
Features enable code coverage collecting using the gcov tool. The
resulting reports can then be post-processed by lcov or similar tools.
[ChangeLog][CMake][Coverage] Added the coverage configuration argument.
The only supported coverage tool at the moment is gcov. The argument
requires Qt is built in Debug otherwise setting the argument leads to
the configuration error. Typical usage:
<...>/configure -developer-build -coverage gcov
Task-number: QTBUG-86223
Change-Id: I39b2061f544997a7c4fe6f4d135c0ab447f15a17
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
It's unlikely that C++ code needs to query that feature. It also
causes full rebuilds of Qt if the feature's value is toggled.
Remove the no-prefix define from qconfig_p.h.
Pick-to: 6.5 6.6
Task-number: QTBUG-116689
Change-Id: I7d968b1c3d6bff3653e1233cea09a36579776347
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
The displayed failure messages were missing the label, making the
output confusing.
Pick-to: 6.5 6.6
Change-Id: I4e20687f85b651dcac66ebd6e0881809dc0be709
Reviewed-by: Amir Masoud Abdol <amir.abdol@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
In Qt 5 times, if Qt was configured with -make examples, running
make install would not only build and install the example binaries,
but would also install the example sources into the prefix.
Installation of example sources was not implemented when the Qt 6
build system has switched to using CMake.
There is still a use case for it though, mainly for Qt Creator, which
only shows the examples of a Qt kit if the sources are available.
In contrast to Qt 5, in Qt 6 we will not install example sources
by default. It will be opt in.
To enable installation of examples sources, configure with
configure -make examples -install-examples-sources
or
cmake -DQT_BUILD_EXAMPLES=ON -DQT_INSTALL_EXAMPLES_SOURCES=ON
The -make examples part is required, otherwise
-install-examples-sources has no effect.
All example sources can be installed by calling
cmake --install . --component examples_sources
in the qt repo build directory.
In a top-level build, per-repo installation can be done using
cmake --install . --component examples_sources_<repo_name>
where repo_name could be 'qtbase'.
A single example's source can be installed by calling
cmake --install . --component examples_sources_<subdir_name>
where subdir_name is the subdirectory name of the example, e.g.
'gallery'.
Implement installation of example sources by hooking into the
qt_internal_add_example command.
This means that all examples in all repos need to be added via
qt_internal_add_example instead of add_subdirectory, to ensure the
sources are installed. The majority of repos already use it.
For testing purposes one can configure with
-DQT_BUILD_EXAMPLES=ON -DQT_INSTALL_EXAMPLES_SOURCES=ON
-DQT_INTERNAL_NO_CONFIGURE_EXAMPLES=ON to allow testing installation
of examples sources without building them.
Take into account an additional variable called
QT_INTERNAL_EXAMPLES_SOURCES_INSTALL_PREFIX to allow installation of
example sources into a location different from the example binaries.
As a cleanup, the NAME option that could previously be passed to
qt_internal_add_example_external_project has been removed.
That's because it's never used anywhere and could not have worked
anyway because qt_internal_add_example_in_tree never handled it.
Pick-to: 6.6
Fixes: QTBUG-112135
Change-Id: I52aa5ec643ff7e212276c88d8dd2dfecdbdbeb0d
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
I added the ability to use `-no-unity-build`, and included the
batch size in the config.summary as well. In addition, qt_feature is not
being used for `-unity-build` anymore.
Pick-to: 6.5 6.6
Change-Id: I4a10e03d3505336d2256280ed2854ec0425df47f
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Vcpkg detection is enabled by default, but we did not have a flag to
disable it, and it was not showing up in config.summary either. By
adding a -vcpkg flag, we get to use `-no-vcpkg` when necessary, as well
as adding an entry to config summary indicating whether vcpkg is in use
or not. Besides `-no-vcpkg`, one can pass `-DQT_USE_VCPKG=OFF` to cmake
command in order to disable the automatic vcpkg detection/integration.
[ChangeLog][configure] vcpkg detection, and integration can be disabled
by passing the -no-vcpkg flag to the configure command, or by passing
`-DQT_USE_VCPKG=OFF` to the cmake command.
Pick-to: 6.6
Change-Id: Ide8da70a7b473ec23995104d162356e75e6d1240
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
As mentioned, separate debug info will always be generated when building
with `-release -force-debug-info`.
Pick-to: 6.5 6.6
Fixes: QTBUG-108015
Change-Id: I49e79177ca833007b932b58a76261c07acd52ca6
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
TestCocoon is not maintained anymore, and the -testcocoon configure
option of Qt didn't do anything useful since Qt 6.0.0.
Remove the option. It's possible to create an instrumented build by
using dedicated CMake toolchain files as described in the documentation
of Squish Coco (TestCocoon's replacement).
Fixes: QTBUG-88316
Change-Id: I8a565cdd288aca9208f48138d2b663802cc0de90
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
I think this needs to be more prominent, as I noticed during the testing
that it could cause issues if it gets lost in between the config
messages, as we knew of course.
Pick-to: 6.5 6.6
Task-number: QTBUG-113463
Change-Id: I2ece498a8d3604362a49cc10499b92b0d2764fb9
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Without enabling FEATURE_msvc_obj_debug_info ccache does not work
for me with msvc.
So, enable it along with -ccache to make things easier.
Change-Id: Ic6cf6ebddb4a5dce6a04987fba1a1f437b286e90
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
It's unlikely we will ever use pro2cmake at this project stage,
so it doesn't make any sense to keep the 'special case' markers
in the CMake scripts. Remove them and replace with TODO where
needed.
Change-Id: I84290c20679dabbfdec3c5937ce0428fecb3e5a7
Reviewed-by: Amir Masoud Abdol <amir.abdol@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Qt requires them and will fail to build if it isn't met, so we don't
need to check for its support. These were public CMake and qmake
features, so to keep compatibility with existing they're hardcoded now
(only done for the C++ editions and for qmake only, as that's what Qt 5
did).
Change-Id: I7f354474adce419ca6c2fffd174814724f45f90b
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Maintain one central place - .cmake.conf - for information
about Qt's copyright.
Pick-to: 6.2 6.5
Change-Id: Ibcbce4313eba9660d459061b0ad00307e267b8f7
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Add it globally so that each module using tracepoints don't have to
add it themselves to each modules configure.cmake.
Pick-to: 6.5
Change-Id: Id58cfaff5cd715b2667da2470001d646117f9f28
Reviewed-by: Tomi Korpipää <tomi.korpipaa@qt.io>
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
As of f68e2c92cc0ed2c1929140402c061359bc2363a5, and its follow up
changes, we can now link individual plugins statically, even if the
Qt build is generally a shared build.
This allows us to build Qt for iOS as shared libraries, while still
keeping the platform plugin as a static library, since this is
harder to port over to a shared library.
This gives the benefit of faster turnaround during development, as
well as binary compatibility promises for the main Qt libraries,
without having to go fully shared for all of Qt.
Static builds are still the default, due to the downsides of larger
application bundles and slower load times for shared builds.
For now the user has to manually tick the "Embed & Sign" check
box in Xcode for each Qt library, which is only available with
Xcode projects generated by the qmake Xcode generator.
Task-number: QTBUG-85974
Change-Id: Id2b7bd2823c8e7c79068dda95295b574ada8d7f2
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Make options for enabling "simd128" and "exceptions" public:
-feature-wasm-simd128
-feature-wasm-exceptions
Make sure both appear in the config summary and feature
list. Move the exceptions code so that they are next to
each other in the cmake file.
Pick-to: 6.5
Change-Id: I3975b56703f40f7ffff270754535bc2eb5bfe488
Reviewed-by: Mikołaj Boc <Mikolaj.Boc@qt.io>
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
clang-cl's intrinsics support is broken, it doesn't declare the AVX2
intrinsics if they are disabled and this doesn't match GCC or MSVC
behavior: https://github.com/llvm/llvm-project/issues/53520
This fix allows to disable x86 intrinsiscs during configuration of
clang-cl build.
clang-cl build is still not guaranteed to work with enabled x86 intrinsics.
Change-Id: Icd295f6b4d868adf10bcd425d5280c56b43cb9f7
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Otherwise certain features may act as enabled even though they're
not supposed to be
Pick-to: 6.4
Fixes: QTBUG-108611
Change-Id: Id4b4bcb7a8f437e2d12b2a2f9b3ce2d4463b8be8
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Add support for enabling -fwasm-exceptions at compile and
link time, which enables use of C++ exceptions.
Wasm-exceptions is an in-progress roadmap item (see
https://webassembly.org/roadmap/), but is supported
by the major browsers
Change-Id: I6e2847206a46ed8038320c99725bc09a0344d1b4
Reviewed-by: Aleksandr Reviakin <aleksandr.reviakin@qt.io>
Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
Locally I cannot build Qt with the default ld linker.
Only enabled bfd and lld because mold and gold is not available
for Windows.
Pick-to: 6.4 6.2
Change-Id: Ib57562b07219acc47f53fe5b0944f54d9c2a6ba6
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Add Qt configure feature for enabling WebAssembly SIMD usage:
./configure ... -feature-wasm-simd128
Enabling this feature makes Qt add the -msimd128 flag to
the compile options, which enables SIMD instruction usage
for the compiler.
(This should not be confused with the previously added SSE
SIMD support, which uses Emscripten's support for translating
SSE SIMD to WASM SIMD)
Change-Id: I84a36ccef8abf9199c304d68ce371c6b1747b832
Reviewed-by: David Skoland <david.skoland@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
OpenSSL by default doesn't provide static libraries and we would fail to
build it in such case.
Fixes: QTBUG-106978
Change-Id: I456fe9bec2bbef5003de8f6cb7d9d8bb226821f9
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
The full name should obviously indicates what the feature is, no need to specify LTO explicitly. And it also make the line a little longer than it should be. But we should keep LTCG (Link Time Code Generation) in case the user don't know LTCG also refers to this feature.
Change-Id: I95a2e5335d0b76c40c67f0484d77a4d50f5fd85f
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Use OpenSSL 3.0 as a provider of all hashing algorithms, except the
BLAKE2b and BLAKE2s. BLAKE2b and BLAKE2s algorithms support a variable
length digest, but OpenSSL's implementation outputs only a digest of a
fixed length (the maximum length supported). This is 512-bits for the
BLAKE2b and 256-bits for the BLAKE2s and for that reason we still use
the original implementation.
[ChangeLog][QtCore][QCryptographicHash] Uses the OpenSSL 3.0
implementation now, where available.
Change-Id: Ia4e4139b92ea9b40a18aa480aa5c06562178f916
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Keep the line short. While at it, also mention Intel, because
that's where the technology is available at (and searching for
Intel CET will lead you to the right places).
Change-Id: Iefe0d735a814880d49fbe82cfd3a790af656377e
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
This implements the build system bits required to build Qt
as as separate wasm modules a.k.a Emscripten side modules.
Enable by configuring with the "-shared" flag.
This is the first step towards shared library support and gets
us as far as being able to load QtCore and instantiate a
QCoreApplication.
Task-number: QTBUG-63925
Change-Id: Ib8f07f80fb5b13c8dbba65c7db735dc557b70d0e
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
CMakeLists.txt and .cmake files of significant size
(more than 2 lines according to our check in tst_license.pl)
now have the copyright and license header.
Existing copyright statements remain intact
Task-number: QTBUG-88621
Change-Id: I3b98cdc55ead806ec81ce09af9271f9b95af97fa
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
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>
