Capture the output of the check_cxx_source_compiles calls in
qt_internal_add_link_flags_no_undefined like we do for
qt_config_compile_test.
Amends 3334a77ecfb792fba0144e99887f11cd0fa2506d
Pick-to: 6.8
Task-number: QTBUG-137198
Change-Id: Ic7dd4eae0ac1af0f8293f2ce285d2987e4e26249
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
(cherry picked from commit 7542aaea604907ff69ed03f650421403388b5463)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
(cherry picked from commit f35f45642c96581ebeed06e0dba7451fec36fe26)
This changes the error message I get when configuring with
-DFEATURE_sanitize_thread=ON from:
CMake Error at cmake/QtFlagHandlingHelpers.cmake:183 (message):
Platform linker doesn't support erroring upon encountering undefined
symbols. Target:"Core".
Call Stack (most recent call first):
cmake/QtModuleHelpers.cmake:898 (qt_internal_add_link_flags_no_undefined)
src/corelib/CMakeLists.txt:30 (qt_internal_add_module)
to:
ERROR: detected a std::atomic implementation that fails for function pointers. Please apply the patch corresponding to your Standard Library vendor, found in qtbase/config.tests/atomicfptr
CMake Error at cmake/QtBuildInformation.cmake:240 (message):
Check the configuration messages for an error that has occurred.
Call Stack (most recent call first):
cmake/QtBuildInformation.cmake:59 (qt_configure_print_summary)
cmake/QtBuildRepoHelpers.cmake:393 (qt_print_feature_summary)
cmake/QtBaseHelpers.cmake:287 (qt_build_repo_end)
CMakeLists.txt:36 (qt_internal_qtbase_build_repo)
Pick-to: 6.8
Change-Id: If6243362521802d8b1348ae53d744c33add814f1
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
(cherry picked from commit c29868830c5e1fc208f8055157dc0fcdb8f1e13d)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Helper function that groups together compiler specific options and conditions
Pick-to: 6.8
Change-Id: Ibec52a19852ad528007f50316a52d2f867b5fe37
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
(cherry picked from commit 167b38712d2d8157393e0753f11c6c41b1740de5)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
To more easily spot white space differences.
Pick-to: 6.8
Change-Id: I1e07960f78c95ca536243ce5c4fc6c302c47a7db
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
(cherry picked from commit 2dd0c4520fdee50a3511ca2f83decdf807ba2cb3)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Xcode enables additional warnings that we are not warning-clean from.
It also sets C++ hardening explicitly, which clashes with our own
hardening define, causing a warning. Attempts at solving this via
generator-specific genex or propagating interface properties on
PlatformCommonInternal did not succeed.
https://gitlab.kitware.com/cmake/cmake/-/issues/26321
Pick-to: 6.8
Change-Id: I5ae4eb3006fcd8152441b6470879123076de8e58
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Add the WARNINGS_ARE_ERRORS flags unconditionally, so developers may
control skipping per-target or per-repo.
This allows setting the WARNINGS_ARE_ERRORS cmake option for each repo
independently when configuring them. So qtbase might be built without
the flag enabled and setting the WARNINGS_ARE_ERRORS to TRUE for
the depending repo enables it for the internal Qt targets.
Add the new internal function that controls the related internal flag.
Keep qt_skip_warnings_are_errors for compatibility since it's used
in qtwebengine.
Combine qt_internal_set_skip_warnings_are_errors and
qt_skip_warnings_are_errors_when_repo_unclean functionality in the
new qt_internal_default_warnings_are_errors function.
Change-Id: I1330c75cd67a24e6386f5e94a089e43fa2012bc4
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The QT_DECLARE_Q{,E}SDP_SPECIALIZATION_DTOR_WITH_EXPORT macros make the
destrcutor of the particular instantiations be out-of-line and exported
from the library in question. In many cases, the class name that is
being instantiated can found in a _p.h and this causes syncqt to mark
any use of this class as private API, including this constructor that is
meant to be used from inline (user) code.
This patch marks all such instantiations to be "public" API. That will
include some uses that shouldn't be so marked, but this is easier than
having to do it piecemeal.
The ELF version was changed for thsee Symbols changed in QtGui (for example):
QExplicitlySharedDataPointer<QPlatformPixmap>::~QExplicitlySharedDataPointer()
QExplicitlySharedDataPointer<QColorSpacePrivate>::~QExplicitlySharedDataPointer()
QExplicitlySharedDataPointer<QPageRangesPrivate>::~QExplicitlySharedDataPointer()
QExplicitlySharedDataPointer<QColorTransformPrivate>::~QExplicitlySharedDataPointer()
QExplicitlySharedDataPointer<QPdfOutputIntentPrivate>::~QExplicitlySharedDataPointer()@@Qt_6
QExplicitlySharedDataPointer<QEventPointPrivate>::~QExplicitlySharedDataPointer()
QExplicitlySharedDataPointer<QPageRangesPrivate>::~QExplicitlySharedDataPointer()
QExplicitlySharedDataPointer<QColorTransformPrivate>::~QExplicitlySharedDataPointer()
QExplicitlySharedDataPointer<QPenPrivate>::~QExplicitlySharedDataPointer()
QExplicitlySharedDataPointer<QFontVariableAxisPrivate>::~QExplicitlySharedDataPointer()@@Qt_6
QExplicitlySharedDataPointer<QPlatformPixmap>::~QExplicitlySharedDataPointer()
QExplicitlySharedDataPointer<QColorSpacePrivate>::~QExplicitlySharedDataPointer()
QExplicitlySharedDataPointer<QEventPointPrivate>::~QExplicitlySharedDataPointer()
QExplicitlySharedDataPointer<QPenPrivate>::~QExplicitlySharedDataPointer()
Pick-to: 6.8
Task-number: QTBUG-128656
Task-number: QTBUG-117514
Change-Id: I1f25f1e61bb98159f9d3fffd63acbe04098cfef6
Reviewed-by: Dennis Oberst <dennis.oberst@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@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>
Some Qt internal targets might not work correctly when built with
Intel CET hardening.
Add a per-target opt out to skip adding the Intel CET flags.
Pick-to: 6.8
Task-number: QTBUG-127464
Change-Id: I1a28b228a82b3505d987649eec6db08281c15482
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
The new approach allows to imply the macro definitions for every Qt
submodule and user project without the need of setting it explicitly
from CMake. This also prevent users from introducing the
incompatibility between Qt modules due to defining
the QT_DISABLE_DEPRECATED_UP_TO version lower than qtbase was built
with.
Task-number: QTBUG-124765
Change-Id: I7ba481f62cb9073ae0343c400ffc26f239f080f1
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The Qt CMake routines for generating pkg-config files don't
handle all sorts of generator expressions, see
qt_internal_set_pkg_config_cpp_flags in QtPkgConfigHelpers.cmake
which hardcodes handling of some specific expressions. In this
case, they don't handle the semicolon within the generator
expression expansion.
For the UNICODE and _UNICODE defines, this means that the pkg-config
file ends up containing "-D_UNICODE>" with the trailing ">". (The
pkg-config generator tries to parse out the generator expressions,
but the semicolon gets handled as a higher level separator, leaving
the closing bracket ">" behind.)
This issue only shows up for mingw targets, because pkg-config files
aren't generated in MSVC style builds.
Escape the semicolon as $<SEMICOLON> to make it not break the
surrounding generator expression, as parsed by the pkg-config file
generator.
The generator expressions aren't fully correctly evaluated for the
pkg-config files though; the UNICODE and _UNICODE defines don't
end up in the resulting pkg-config file even though they're used
during compilation (both before and after this change).
Fixes: QTBUG-103019
Co-authored-by: Martin Reboredo <yakoyoku@gmail.com>
Pick-to: 6.7 6.5 6.2
Change-Id: Icdb380e3b42be2a47372a8ee2b61378a33c685f7
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Li Xinwei <1326710505@qq.com>
Build system adds this flag to any module that it uses when built as a
shared library and not WASM.
VxWorks is specific in regards to type of applications:
- static application, which do not use any dynamic libraries
- dynamic application, which uses shared libraries, and as such needs
to link against libdl.a
The latter is the only source of symbols related to dynamic loading and
thread local storage. This is an architectural decision, as application
is required to embed loading tools in itself (as opposed to Unix/Linux,
which contains dynamic loader which provides these symbols separately).
libdl.a is standard static library on VxWorks, compiled without PIC, and
as such can't be linked into shared library.
This results in compilation errors when building dynamic libraries which
use `thread_local`-related symbols, since these symbols will be
fulfilled at runtime (contained in executable which requires shared lib)
and are not available during linking.
Don't add `-Wl,--no-undefined` flag on VxWorks for Qt shared lib builds.
Task-number: QTBUG-115777
Change-Id: I47e5d68afcba2c3b4203e4c0beded2e18ea2563b
Reviewed-by: Pasi Petäjäjärvi <pasi.petajajarvi@qt.io>
QFuture::then() uses QtPrivate::Continuation::create(), which in turn
uses private API from an inline function:
f->d.setContinuation(ContinuationWrapper(std::move(continuation)), fi.d);
f->d is QFutureInterfaceBase (a public class), but its setContinuation()
takes QFutureInterfaceBasePrivate by pointer. Our ELF versioning scripts
mark everything that uses that class as private, resulting in:
4806: 0000000000287d70 365 FUNC GLOBAL PROTECTED 16 _ZN20QFutureInterfaceBase15setContinuationESt8functionIFvRKS_EEP27QFutureInterfaceBasePrivate@@Qt_6_PRIVATE_API
This commit adds an exception for this symbol, causing it to go back to
the regular "Qt_6" ELF version:
5629: 00000000003d6a16 366 FUNC GLOBAL PROTECTED 16 _ZN20QFutureInterfaceBase15setContinuationESt8functionIFvRKS_EEP27QFutureInterfaceBasePrivate@@Qt_6
This solution can probably be cleaned up a bit by moving the marker into
the header files parsed by syncqt, so they follow code motion without
having to remember to update the CMakeLists.txt. That requires some
surgery with syncqt, so not suitable for cherry-picking.
As a drive-by, fix the target_type check
for the _qt_extra_linker_script_content genex property
Fixes: QTBUG-117514
Pick-to: 6.6
Change-Id: I85599ea5ca7a4b79a8bbfffd178b92e73dbe11de
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
A little code simplification. And we can enable exception handling
explicitly for GCC/Clang by adding "-fexceptions", it was missing
in the old code, add it as well.
[ChangeLog] [Build System] Qt explicitly pass -fexceptions now on
non-MSVC toolchains, if exception handling is not disabled in CMake
configure.
Change-Id: Id9d61d3ee8b7d490f4a743e34e8be321af080be0
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
I added this flag but only explained what it is in the original
commit message, it may confuse future code readers without some
inline comments. So add some comments to avoid such issue.
Change-Id: I6a3c0f53c2bc58646cc70e45cacb1d0e40656c0a
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Commit 946f15efb76fffda37b77f7d194d679b904305b1 added the line
extern "C++" { std::* };
but that was too good to be true. The intention was to catch Standard
Library inline symbols that got emitted in our own libraries, not use of
Standard Library types in our symbols. Unfortunately, that glob
expression matches the demangling literally and return types for
templates are demangled in their usual position to the left of the
function name.
For example,
std::random_device qFoo(); // mangles as _Z4qFoov → "qFoo()"
but
template <typename T> T qFoo();
template std::random_device qFoo<std::random_device>();
mangles as _Z4qFooISt13random_deviceET_v and that demangles to
"std::random_device qFoo<std::random_device>()".
Therefore, we replace that with a full expansion according to the
mangling scheme. This includes a minor fix for the RTTI symbols, to
match nested names too (those with "N" in the name). It can't match
virtual override thunks ("Tv" and "Th"), because those have variable
length names and the matching is done by fnmatch(), not regex.
Pick-to: 6.6
Change-Id: I9d43e5b91eb142d6945cfffd178449cf68669cb6
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Error is the default for this option in ld64, and with the new linker
in Xcode 15 the option was deprecated, causing a warning, so let's just
skip adding it and assume undefined symbols results in errors.
Fixes: QTBUG-116732
Pick-to: 6.6 6.5
Change-Id: I736a891ae102fe1dfb2cdf869f42c665e231adba
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
We've had issues in the past where Standard Library constructs either
with or without a Qt type mangled in the middle get exported from our
ABI and thus get marked with the Qt version numbers. For example, I can
see in our libraries:
517: 000000000010e608 24 OBJECT GLOBAL DEFAULT 22 typeinfo for std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>@@Qt_6
615: 00000000000eb2a0 47 OBJECT GLOBAL DEFAULT 17 typeinfo name for std::_Mutex_base<(__gnu_cxx::_Lock_policy)2>@@Qt_6
706: 000000000010e5f8 16 OBJECT GLOBAL DEFAULT 22 typeinfo for std::_Mutex_base<(__gnu_cxx::_Lock_policy)2>@@Qt_6
750: 00000000000ed5f0 16 OBJECT GLOBAL DEFAULT 17 std::_Sp_make_shared_tag::_S_ti()::__tag@@Qt_6
754: 00000000000da408 1 OBJECT GLOBAL DEFAULT 17 std::piecewise_construct@@Qt_6
This causes user content to break when an update to Qt stops exporting
such symbols, either because of code changes or because of changes to
the compiler and its optimizer.
In fact, this commit will cause that, for the symbols above. But this
will no longer be random-looking.
[ChangeLog][Important ABI Changes] On ELF-based platforms (e.g., Linux,
FreeBSD), the linking process has been updated to exclude Standard
Library symbols from getting the "Qt_6" ELF version. This solves the
problem of applications and libraries breaking arbitrarily after Qt
updates, but will cause such breakages right now. Content built with
older versions of Qt may need to be relinked.
Change-Id: I5acc02341c5940499682fffd1775edce0021ce6d
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The gc_sections linker flag was recently wrapped in a
$<CXX_COMPILER_ID> genex to prevent adding it the command line when
using an incompatible compiler.
This causes an issue when generating .pc pkg-config files because
$<CXX_COMPILER_ID> can't be used in the output of a file(GENERATE)
call.
Record the flag in a global property, both the genex-wrapped and bare
forms, so that we can perform a string replacement when generating
the pkg-config file to remove the genex wrapping.
This is not perfect, in the sense that consumers of the .pc file
might get the wrong flag if using an incompatible compiler, but
it's better than outright failing the Qt build.
Distros will be expected to patch the .pc files if necessary.
Note the issue does not usually happen for regular Qt builds because
gc_sections is only enabled automatically for static builds, but for
static builds we don't currently generate .pc files.
So the issue only happens in shared Qt builds where the gc_sections
feature is enabled manually.
Amends a2b6c2f3437bf1779da787e719bea08bc6f28622
Pick-to: 6.5 6.6
Fixes: QTBUG-115243
Change-Id: I3f6bdf86c24ee90b6da04994e458b438cc41fc7a
Reviewed-by: Amir Masoud Abdol <amir.abdol@qt.io>
If flags use CMake scopes that propagate them to user libraries, it may
lead to an issue, if user projects are built using different compiler.
We need to guard these flags to make sure that they only will apply to
respective compilers.
Pick-to: 6.5 6.6
Change-Id: I0fd5847447bd8373e8e07f64dae11f27f48c915d
Reviewed-by: Alexandru Croitor (OOO) <alexandru.croitor@qt.io>
Reviewed-by: Amir Masoud Abdol <amir.abdol@qt.io>
Android's toolchain file, ie., android-legacy.toolchain.cmake assumes
that the default build is a Debug build, and it adds the `-g` flag to
CMAKE_<LANG>_FLAGS, as a result, our release Android build always
contains debug symbols. In this patch, I basically move the `-g` flag
from CMAKE_<LANG>_FLAGS to CMAKE_<LANG>_FLAGS_DEBUG, and
CMAKE_<LANG>_FLAGS_RELWITHDEBINFO.
Pick-to: 6.5 6.6
Fixes: QTBUG-111901
Change-Id: I31eadb07d9172c923e8beaf0ac6c6e34fe1ebefb
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Previously, we were not setting the CMAKE_<LANG>_FLAGS, instead we were
only processing the CMAKE_<LANG>_FLAGS_<CONFIG>. This patch amends that
so we also update the default flags list as well.
Pick-to: 6.5
Change-Id: I7ceb87850a806fe8ad4eac6f8147b312eba01bc6
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
There was a discrepancy between what the comment was saying, and what
the function was doing before, and with this patch, we opt for what the
comment was saying, which makes more sense. In addition, I cleaned up
its documentation a bit.
Pick-to: 6.5
Change-Id: I07c20f93aa5c8e9bc942f5e69f0cf8299f4a813e
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
INTERFACE scope propagates the '-utf-8' flag to the target dependencies.
So if Qt is built using MSVC, but the depending targets use different
compiler this flag will break the compilation.
Guard the flag using genex.
Amends e3cc2487ce63cae42d8054b38fdb54abe8545007
Pick-to: 6.5
Task-number: QTBUG-112737
Change-Id: Ie0576667108820dd61035debfc1fcc030ef3536a
Reviewed-by: Lars Schmertmann <lars.schmertmann@governikus.de>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
As described in the bug report, in cases where host Qt is built using
MSVC, these flags may leak to user projects if they are set to be
configured by a different compiler, e.g., Clang.
Pick-to: 6.5
Fixes: QTBUG-112737
Change-Id: Iad922e24cc7e7f835e08ed37271dfbedc6e38dbe
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
lld 16.0 is more picky about symbol versioning than previous versions
(and other linkers such as ld.bfd, gold or mold).
It now errors out if a symbol is versioned but not defined
(see 8796677de8900dc154aef45f8620c3f987a40291).
Outside of detecting support for symbol versioning (fixed by 462832),
this causes linking Qt6 libraries other than Qt6Core to fail because
their linker scripts try to add versioning to qt_version_tag, which is
defined in Qt6Core rather than the library being linked.
The obvious (and working) fix is to version qt_version_tag only where it is
defined (Qt6Core), but this is not what the original intent seems to be.
Task-number: QTBUG-111514
Change-Id: I963d417befb0f6b2260c57f059eeda1fe79200c9
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This replaces the qt_parse_all_arguments macro with the built-in
`cmake_parse_arguments(PARSE_ARGV`. In addition, a new function,
_qt_internal_validate_all_args_are_parsed, can be used to check whether
any _UNPARSED_ARGUMENTS have been passed to the function.
Fixes: QTBUG-99238
Change-Id: I8cee83dc92dc6acdaaf747ea6ff9084c11dc649b
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Avoid using perl in CMake scripts. Remove the syncqt.pl specific
code.
Task-number: QTBUG-87480
Change-Id: I7fcd5cc83d173ec463c275b5b50b84f25044a118
Reviewed-by: Alexandru Croitor <alexandru.croitor@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>
And also teach CMake to treat it properly instead of hardcoding the
version number.
[ChangeLog][Build System] The configure script now accepts a new
parameter -disable-deprecated-up-to which is used to remove all
deprecated code from API and ABI while building the libraries.
The version number must be specified in a hex format.
For example, it can be used like this:
/path/to/qt/configure -disable-deprecated-up-to 0x060500
to remove all code deprecated in Qt 6.5.0 or earlier releases.
Task-number: QTBUG-101510
Change-Id: I557cf83e29b867fa1052bb097985e144b5eaf34d
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The new name describes the behavior in a better way.
[ChangeLog][Build System] The QT_DEPRECATED_WARNINGS_SINCE macro is
renamed to QT_WARN_DEPRECATED_UP_TO. The old name is deprecated, but
is still recognized if it is defined during configuration and the
new name is not defined.
Fixes: QTBUG-104944
Change-Id: I320c033010dfab120db6922598454f95169657f7
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The new name describes the behavior in a better way.
[ChangeLog][Build System] The QT_DISABLE_DEPRECATED_BEFORE macro is
renamed to QT_DISABLE_DEPRECATED_UP_TO. The old name is deprecated, but
is still recognized if it is defined during configuration and the new
name is not defined.
Task-number: QTBUG-104944
Change-Id: Ifc34323e0bbd9e3dc2f86c3e80d4d0940ebccbb8
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Add the support of pre-cooked content for the LD version script. The
content can be generated without using the perl script at configure
or build time.
Change-Id: I1316e114a1d5550b2fdcf3482a51f336fb311a29
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@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>
We're in 2022. A 11-year-old C standard probably suffices, especially
since we require C++17 anyway.
Pick-to: 6.4
Change-Id: Ibcde9b9795ad42ac9978fffd16f3555327097ded
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
add_custom_command with PRE_LINK doesn't work correctly with
Multi-Config builds. The better solution is to introduce a custom
target that generates the final version script and link the target to
the library target as the dependency.
Change-Id: Ib7420af752a6a46f29f411f9f0dc8557410b4f22
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
When building Qt we should have warnings of any internal use
of deprecated API, so set it to Qt7.
Also added comments to clarify what the macros do.
Change-Id: Ib47278fed9ab1ec4411ed9f69a9a9c0f811db02d
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Use VERBATIM option to prepare the correct command line for the
add_custom_command. This especially sensitive when using build
directories with names containing special symbols, that cannot be
handled by shell correctly.
Change-Id: I51d7041cb806411135fd59bf6273c04a3c695443
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
1. Clang-CL can't recognize "/d2FH4" and it's causing
lots of warnings when compiling. So don't apply it
when building with clang-cl.
2. The definition of "FS_INFORMATION_CLASS" need to
be visible to clang as well. Don't know why it was
excluded originally.
Pick-to: 6.3
Change-Id: I7b6e14999eea0ba1f0d73962ff03a35548f88a5a
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
When compiling CUDA sources in a user project, the Qt6::Platform target
would pull in C/C++ related compiler flags, leading to compiler errors.
Make sure that we only add those flags to C/C++ source files.
Pick-to: 6.2 6.3
Fixes: QTBUG-99548
Change-Id: Idbccd65fe8f66abd1da3fce95e563065d1ed3cc6
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
Visual Studio 2019 introduced the dubbed FH4 feature
which can make C++ exception handling smaller on x64.
According to the article [1], it's enabled by default
for UWP applications, and Microsoft also use it in
their own widely-known commercial products such as
Office to reduce the binary size.
So make use of this feature for Qt when possible, to
get smaller binary.
As a drive-by, add "/EHs-c-" explicitly to the flags
when we want to disable C++ exception handling.
[1] Official article that introduces dubbed FH4:
https://devblogs.microsoft.com/cppblog/making-cpp-exception-handling-smaller-x64/
Change-Id: I2e3330de477f78372cf7903d0ef7a732b09552a9
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: André de la Rocha <andre.rocha@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
This hasn't worked for some time. It's not in our CI and I don't think
it was working at all. When I tried to build it, I ran into several
problems with C++17 and an Internal Compiler Error I did not have any
interest in working around.
After discussing with the Intel compiler team, it was decided that
fixing those issues in the old compiler is not going to happen. Instead,
their recommendation is to adopt the new LLVM-based compiler, which
the last commit added support for.
This commit does not remove qmake support for the old ICC. It's possible
someone is using qmake with a non-Qt6 project and ICC.
Change-Id: Icb2516126f674e7b8bb3fffd16ad6350ddbd49e5
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This includes a few cleanups to our .cmake files where it was easier to
combine existing sections of Clang / AppleClang that no longer needed to
be distinct.
icpx could be replaced with a shell script:
exec `basename $0`/clang++ --intel "$@"
tst_qnumeric is not passing
FAIL! : tst_QNumeric::classifyF() Compared values are not the same
Actual (qFpClassify(tiny / two)): 2
Expected (FP_SUBNORMAL) : 3
Loc: [/home/tjmaciei/src/qt/qt6-icx/qtbase/tests/auto/corelib/global/qnumeric/tst_qnumeric.cpp(344)]
FAIL! : tst_QNumeric::classifyD() Compared values are not the same
Actual (qFpClassify(tiny / two)): 2
Expected (FP_SUBNORMAL) : 3
Loc: [/home/tjmaciei/src/qt/qt6-icx/qtbase/tests/auto/corelib/global/qnumeric/tst_qnumeric.cpp(344)]
FAIL! : tst_QNumeric::floatDistance(denormal) Compared values are not the same
Actual (qFloatDistance(from, stop)): 0
Expected (expectedDistance) : 4194304
Loc: [/home/tjmaciei/src/qt/qt6-icx/qtbase/tests/auto/corelib/global/qnumeric/tst_qnumeric.cpp(408)]
FAIL! : tst_QNumeric::doubleDistance(denormal) Compared values are not the same
Actual (qFloatDistance(from, stop)): 0
Expected (expectedDistance) : 2251799813685248
Loc: [/home/tjmaciei/src/qt/qt6-icx/qtbase/tests/auto/corelib/global/qnumeric/tst_qnumeric.cpp(408)]
P
Change-Id: Icb2516126f674e7b8bb3fffd16ad59431e8c3379
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
