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 946f15efb7 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 a2b6c2f343
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>
Removing flags based on REGEX may include spaces, so flags might be
glued. Replace flags with spaces to keep at least one space for
the described case.
Pick-to: 6.2 6.1
Fixes: QTBUG-94400
Change-Id: Ice268da36174ef5cf4398d2aee8fcd4731336316
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
qmake had support for building with clang-cl as the win32-clang-msvc mkspec.
Task-number: QTBUG-89642
Task-number: QTBUG-88081
Change-Id: I0709c289f90fedb121620d1e67ef841602219816
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
After discussion we decided to opt-out the UNICODE definintion
behavior. To disable UNICODE in user projects the
qt6_disable_unicode_defines function could be used.
Amends 5b64e5950c
[ChangeLog][CMake] Enables the UNICODE and _UNICODE definitions on
WIN32 platforms by default for all cmake projects to reflect the
qmake behavior. Use qt6_disable_unicode_defines function to disable
the default unicode definitions.
Pick-to: 6.1
Fixes: QTBUG-93895
Change-Id: Id70ff7dcf8c74f660ec851f8b950e1e3b94d9fb4
Reviewed-by: Alexandru Croitor <alexandru.croitor@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>
The code branch for the INTERNAL argument did nothing, and we never call
qt_internal_add_linker_version_script with INTERNAL.
Change-Id: Ie369b4dac29cd1a977433ebfd662c198a3e1d0f2
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Cristian Adam <cristian.adam@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>
Add internal function to cleanup compiler flags out of the
CMAKE_xxx_FLAGS_xxx variables. Use introduced interface to clear
the '/EHsc' flag for the MSVC compiler family. This adjusts the
CMake behavior to the qmake one.
Change the 'EXCEPTIONS' option handling in helper functions. Add
ability to add enabling and disabling exception flags. Previously
it was only possible to add disabling exception flags.
Fixes: QTBUG-89952
Change-Id: I60d47660a97ae9b5a1d1f4107d352c9e97890144
Reviewed-by: Craig Scott <craig.scott@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
By not including ASM in the languages for which compiler flags are
adjusted, we can end up with inconsistent optimization and debug
settings between different languages. Make sure they are treated the
same.
Similarly, linker flags for MODULE target types should also have their
debugging and incremental linking flags adjusted, just like EXE and
SHARED targets. When building with MSVC, MODULE targets were having
the relevant flags stripped, but not then replaced with the desired
ones, leaving them empty in typical scenarios. This would primarily
affect plugins, which are built as MODULE rather than SHARED libraries.
Fixes: QTBUG-90237
Change-Id: I648ea74be1654d24cbecc592ce0ca4b59b2ae839
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Add '_WINDLL' definition for the MSVC compilers family.
Check the 'FEATURE_optimize_size' value before replacing compiler flags
in the qt_internal_add_optimize_full_flags function. This is required,
because Qt::Core and Qt::Gui modules lost their ability to shrink,
when selecting the appropriate build type or features.
Fixes: QTBUG-89952
Change-Id: I982c25ea84e4793b4006ead0ee516b3f3eb2a054
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Functions in QtFlagHandlingHelpers.cmake try to update the CMake cache
variables for compiler and linker flags. These were using the current
value of those variables and writing the modified ones back to the
cache every time CMake ran. If a toolchain file sets or modifies any of
these variables, that updated value is used and written back into the
cache instead of the original cache variable's value. The next time
CMake executes, the toolchain file re-applies the same change and the
variable grows longer each time with flags repeated. With Ninja, this
causes a complete rebuild every time CMake is re-run. The Android NDK
toolchain file is one example where this behavior is triggered (the
fault is shared, one could argue that the NDK should only be setting
..._INIT variables, but that's out of our control).
Another related bug in the previous implementation was that the flags
used to build after the first CMake execution could be different to
those used for all builds after the second and later CMake runs. This
is because the CMake cache was being updated, but not always the
calling scope of the functions that modified them. If a toolchain file
set any of the compiler or linker flag variables as non-cache
variables, then updating the cache variable would have no effect on
the calling scope. The non-cache variable would continue to take
precedence for that scope for that run. The next time CMake executes
though, the updated cache variable would now have been used by the
toolchain file and the change *will* be part of the non-cache
variable's value.
The above are examples of why you should try to avoid updating these
cache variables from project code. We could leave the cache alone and
always update only non-cache variables, but then a developer looking
at the cache may wonder why the values they see there don't match the
values being used in builds. Or worse, they think the cache values
are being used and don't realize the builds are using something
different. Ultimately, we have to choose which downside we are happy
to live with. The changes here preserve the previous intent of
updating the cache, but it's still a bit fragile.
Fixes: QTBUG-89821
Task-number: QTBUG-85992
Task-number: QTBUG-86866
Change-Id: I8a16753e159bde338e6d2e5dd2ce91fc8ac5c39d
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
*Not* using /permissive- exposes Qt and client apps to interesting
bugs and/or build failures, (e.g. QTBUG-87225, or
19b5520abf). We demand strict
conformance by any other compiler, it's time to demand it from
MSVC too.
The Windows headers themselves are clean starting from the
Windows Fall Creators SDK (10.0.16299.0), and moreover Qt 6 will
drop WinRT; therefore, the comment in the mkspecs does not apply
any more.
Since /permissive- implies /Zc:referenceBinding, drop that
option. The other implied options are set on MSVC < 2017,
but I leave them in to avoid tinkering with the fragile lists
of C/C++ flags.
Rename the CMake internal helper function to better describe
what it does.
Fixes: QTBUG-85633
Fixes: QTBUG-85637
Fixes: QTBUG-85635
Fixes: QTBUG-88244
Change-Id: Ie03fddb61aa066fdc14b7231c22e7108b4a02fbb
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
1. clang-cl doesn't support "-fno-exceptions", it uses msvc's parameter.
2. some parameters supported by msvc are not supported by clang-cl
and they are causing huge warning message flood, don't add them.
3. use correct optimize parameter for clang-cl.
Change-Id: Idbadf139127143c5fa6c49068588cb26f47da7a2
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
