In case they get erroneously extracted. For example, in Core5Compat,
QTextCodec appears in the _p.h as a full class if !QT_CONFIG(textcodec)
(I don't know what that is for, but it's there).
Pick-to: 6.4
Change-Id: Ic6547f8247454b47baa8fffd170eb1d0f7e6d0f9
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
This fixes some threading bugs
Pick-to: 6.4
Change-Id: I1a96dcc54d8338de09b551d52a166d073e85d752
Reviewed-by: Aleksandr Reviakin <aleksandr.reviakin@qt.io>
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
Remove keys that are not needed: CFBundleSignature and
LSRequiresIPhoneOS.
Add CFBundleDevelopmentRegion, which is added by default in new Xcode
projects.
Pick-to: 6.4
Task-number: QTBUG-95838
Change-Id: I090c14561bc812ec255f55001b658d2dc60e11f3
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Emscripten's option for enabling asyncify (-sASYNCIFY) is a link-time
option, which means there is no requirement to have a separate asyncify
build, at least for static builds.
Replace the current QT_HAVE_EMSCRIPTEN_ASYNCIFY compile-time option
with a run-time option which checks if the asyncify API is available.
Keep support for configuring with "-device-option QT_EMSCRIPTEN_ASYNCIFY=1"
for backwards compatibility and for the use case where want asyncify
support to be on by default for a given Qt build.
Enable asyncify for the asyncify_exec example.
Pick-to: 6.4
Change-Id: I301fd7e2d3c0367532c886f4e34b23e1093646ad
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
They should contain the executable suffix .exe when
androiddeployqt is run on Windows, because androiddeployqt does not
add the suffix itself when the tool paths read from the json file.
Amends 4fc14b1933
Amends 176136ce60
Pick-to: 6.4
Fixes: QTBUG-105133
Fixes: QTCREATORBUG-27868
Change-Id: I8c5bac2fa6c82d122f8a70c5ff2a561298327a34
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
If an iOS project was built with qmake using the Makefile generator
instead of the Xcode generator,
so -spec macx-ios-clang, and not -spec macx-xcode,
Asset catalog processing failed with an actool error like
Unknown platform: "ios-simulator"
This is because we used the deployment identifier (which is meant for
creation of the -mios-simulator-version-min flag) to pass a value
to actool's -platform option, rather than the sdk name.
Introduce a new variable called platform_identifier, which will be set
to the currently processed macOS/iOS sdk name (e.g. macosx,
iphonesimulator, iphoneos).
Use it when processing asset catalogs using the Makefile generator.
Relates to 9daeb6fe9d
Amends 5574aa986b
Pick-to: 6.3 6.4
Fixes: QTBUG-102053
Change-Id: Ic4ea3b9e11c21ae535d6544cbed3670f9db44e72
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Developers can add to Emscripten's EXPORT_RUNTIME_METHODS
by defining their own using:
QT_WASM_EXTRA_EXPORTED_METHODS
Which will add on to Qt's default exported runtime methods
of UTF16ToString,stringToUTF16
for cmake:
set_target_properties(<target> PROPERTIES QT_WASM_EXTRA_EXPORTED_METHODS "ccall,cwrap")
or
set(QT_WASM_EXTRA_EXPORTED_METHODS "ccall,cwrap")
for qmake:
QT_WASM_EXTRA_EXPORTED_METHODS = ccall,cwrap
Done-with: Mikolaj Boc
Fixes: QTBUG-104882
Pick-to: 6.4
Change-Id: I9678bdb7b077aaa8527057212ea4e161c0be0b60
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This amends commit fc2e40e88d.
For Qt plugins, we do not add 'dlltarget' to INSTALLS but only 'target'.
In this case we must add the .dll.debug file to 'target' like we did
before fc2e40e88d.
Fixes: QTBUG-105374
Pick-to: 5.15 6.2 6.3 6.4
Change-Id: If495548dfca55d02e1c5884e03e281e27ee07ccd
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
All versions down to 6.2 require at least Xcode 12, which ships with
the macOS 11 SDK, and iOS 14 SDK.
Pick-to: 6.4 6.3 6.2
Change-Id: I128321ec9e97b670b7c027f1233978e1b8856f88
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
It's perfectly possible to create static plugins in an otherwise shared
Qt build, but the logic to import these plugins into applications was
assuming a fully static Qt build. We now handle this more granularly.
Change-Id: Iacfa72f04c7918613b50ca87cf123e7f4c0841d5
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Sanitizing the contents of the QTPLUGIN variable, and adding default
plugins from the available modules, should be a separate step before
the resulting QTPLUGIN is iterated and processed by for example linking
to each plugin, generating an import file, and adding module dependencies.
This makes it easier to add logic to the processing step later on.
Change-Id: I00e826c7fe87b29cf2e6bf4e1901c4d1482a20e6
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>
Clang has the option, but spells it differently.
Fixes: QTBUG-105002
Pick-to: 6.4
Change-Id: I36b24183fbd041179f2ffffd170217e82ff6d14d
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The existing mkspecs for Raspberry Pi 4 (devices/linux-rasp-pi4-v3d-g++) was intended to compile Qt application for the 32-bit version of Raspberry Pi, thus it used compiler flags that are incompatible when compiling Qt application for the ARM 64-bit architecture. According to ARM compiler documentation, -mfpu flag is rejected by AArch64 state while its alternative, -mcpu, has to be avoided when -march flag is already defined. -mfloat-abi flag is not valid with AArch64 targets.
To support both 64-bit and 32-bit architectures, I proposed to add this new mkspecs.
See:
https://developer.arm.com/documentation/101754/0618/armclang-Reference/armclang-Command-line-Options/-mfpuhttps://developer.arm.com/documentation/101754/0618/armclang-Reference/armclang-Command-line-Options/-mfloat-abi
Pick-to: 6.3 6.4
Change-Id: I36574875e798281688601edd0f166922592d9830
Reviewed-by: Tatiana Borisova <tatiana.borisova@qt.io>
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
It's deprecated as of Xcode 14, and generates a warning message if a
project explicitly enables bitcode. The App Store no longer accepts
bitcode submissions from Xcode 14.
Pick-to: 6.2 6.3 6.4 5.15
Change-Id: Ib1f9d5114ca4d8b1845ecc7a9de0473ee015db33
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The zstd feature might have different values between the host
and target, in which case qmake must tell rcc not to use zstd
when the feature is disabled.
Amends 14546d1816
Fixes: QTBUG-103794
Pick-to: 6.4 6.3 6.2
Change-Id: Ia0378742a50e2a85f59985dea2506d3dda5f28e8
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Recents emsdk versions support specifying the method list without
using brackets. Switch to this syntax since that avoids any quoting issues.
Pick-to: 6.4
Change-Id: Ib7bf8ec3f0d2ef67e8222a23e7af9b368ee99a00
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
This will stop working with the next commit, which merges all basic x86
SIMD intrinsics into one configure test. As a result, linking almost
anything graphical on iOS (which is almost everything) causes the linker
to fail with undefined references to SIMD-optimized versions that didn't
get compiled.
Change-Id: Ib42b3adc93bf4d43bd55fffd16c288f4104a6ccc
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
- USE_WEBGL2 is depreciated, Emscripten now uses MAX_WEBGL_VERSION
- Optimize and remove use of emulated ES2 and ES3, which means
only use WebGL friendly subset.
Users can add USE_ES3=1 and USE_ES2=1 to the final linker arguments
for those respective versions in order to enable using
glDrawArrays and glDrawElements with unbound buffers.
See https://emscripten.org/docs/porting/multimedia_and_graphics/OpenGL-support.html
Pick-to: 6.4
Change-Id: I11ae359966964b3e7aa6e61ccc714c2bfbf61f96
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
...instead of next to the import library.
If separate_debug_info is enabled then we would create an install rule
that puts the .dll.debug file next to the .a file. GDB however expects
the file to be next to the .dll.
Fix the installation rule in separate_debug_info.prf accordingly. This
affects the MinGW packages of Qt 5.15 and user projects targeting MinGW.
Pick-to: 5.15 6.2 6.3 6.4
Fixes: QTBUG-86790
Change-Id: If91c356e7e7f7f4330ebc43691e414929f9beb4b
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Adding specialHTMLTargets to EXPORTED_RUNTIME_METHODS carries the
obligation to actually use it as well; failing to do so makes Emscripten
stop with a reference error on startup.
However, we can't guarantee that Qt will use it in all cases. The
current usage depends on QGuiApplication being used. Application code
could be using QCoreApplication, or no application object at all.
Detect if specialHTMLTargets is present instead, and then enable the code
paths which uses it if that's the case. This means that apps which want
to use e.g. multiple browser windows can opt into support by making sure
EXPORTED_RUNTIME_METHODS contains specialHTMLTargets.
Change-Id: I81105aa01946602fcf593f170e305d7dc9bad3be
Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
According to latest clang source code (llvm-14.0.3) non-fragile ABI
is default for everything but i386 which means we can stop passing the
-fobjc-nonfragile-abi option.
See
https://github.com/llvm/llvm-project/blob/llvmorg-14.0.3/clang/lib/Driver/ToolChains/Darwin.h#L245
This gets rid of the following warning when building a qmake project
for iOS, while targeting the iOS simulator:
clang: warning: argument unused during compilation:
'-fobjc-nonfragile-abi' [-Wunused-command-line-argument
It only happens for the simulator case because Xcode adds the
-fobjc-abi-version=2 option, thus the qmake one gets ignored.
As a drive-by also remove the usage of the -fobjc-legacy-dispatch
option. According to clang sources it should be implicitly used
on iOS.
See
https://github.com/llvm/llvm-project/blob/llvmorg-14.0.3/clang/include/clang/Basic/ObjCRuntime.h#L100
Amends d788f636691df5cae59d44a3828a0ddd58c343d0
Pick-to: 6.2 6.3
Fixes: QTBUG-103001
Change-Id: I06f8e46e40a1f04c5bbc4f177afa035e525dfed6
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Replace the current license disclaimer in files by
a SPDX-License-Identifier.
Files that have to be modified by hand are modified.
License files are organized under LICENSES directory.
Task-number: QTBUG-67283
Change-Id: Id880c92784c40f3bbde861c0d93f58151c18b9f1
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
JavaScripts's BigInt feature provides support for arbitrary-precision
integers. This makes it possible to represent 64-bit integers; the
standard JS Number type supports 32-bit integers only (or more
accurately 53-bit integers - see Number.MAX_SAFE_INTEGER).
Enable WASM_BIGINT which makes Emscripten map int64_t and uint64_t
to BigInt when interfacing with JavaScript code.
This removes one of the conditions which enables
wasm-emscripten-finalize.
Task-number: QTBUG-103352
Change-Id: Ia70d599daaf34c92695f5a2b61665e0c237e6b95
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
Reviewed-by: David Skoland <david.skoland@qt.io>
This removes one of the conditions which enables
wasm-emscripten-finalize.
Task-number: QTBUG-103352
Change-Id: Id05db4b081dec360cdad2e611622e5baf09aeb23
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: David Skoland <david.skoland@qt.io>
PCRE 10.40 requires C99 now. While all GHS compiler versions we support
in Qt 6 default to C99, GHS v2016.5.4, which we use in Qt 5.15, still
defaults to C89, so set QMAKE_CFLAGS_C99 for that compiler. It doesn't
hurt in Qt 6, but enables the updated PCRE in Qt 5.15.
Pick-to: 6.3 6.2 5.15
Change-Id: I0a2d3254f80136210289a415ede7c2409b07af9b
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Kimmo Ollila <kimmo.ollila@qt.io>
The change
0ec75f4b99
missed adding specialHTMLTargets for qmake
Also add warning to keep QtWasmHelpers in sync with qmake.conf
Change-Id: Idb363e77f0cecb4f125d3cb4f7507899149a3bac
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
The textual output of otool in recent Xcode releases has changed.
We now look for OBJC_CLASS_RO/OBJC_METACLASS_RO rather than
class_ro_t.
Pick-to: 6.2 6.3 5.15
Change-Id: I86192e91e55d8deb7e5c6790b327855fc0f7e594
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Add the CONFIG value c++2b that represent the upcoming C++23 standard.
Add QMAKE_CXXFLAGS_CXX2B and QMAKE_CXXFLAGS_GNUCXX2B.
On MSVC, use /std:c++latest when c++2b is active.
This fixes an issue with MSVC where c++latest implied the /std:c++20
compiler flag.
Pick-to: 5.15 6.2 6.3
Fixes: QTBUG-102202
Change-Id: Ie00ee5793c1a649195013c8c19efc8d59cf0acc9
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
If xcrun prints warnings or errors to stderr while determining the SDK
version, they become part of the SDK version string. This then leads to
a qmake error.
Intentionally ignore stderr so that it is not treated as part of the SDK
version.
Pick-to: 5.15 6.2 6.3
Fixes: QTBUG-102066
Change-Id: I023296b430aac1407c970412c5cf1010bd81589b
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
INITIAL_MEMORY and PTHREAD_POOL_SIZE are linker flags only
USE_PTHREADS is both linker and compiler arguments.
Also increase default INITIAL_MEMORY
Pick-to: 6.3
Change-Id: Id1998efbf1d6de901f404db7e988f6cafd547a39
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
The -mno-direct-extern-access tells the compiler and linker that
references to symbols outside this ELF module mustn't be direct and must
instead always go through the GOT or PLT (the PLT can additionally be
disabled with -fno-plt). The ELF protected visibility tells the compiler
and linker that this symbol is present in the dynamic symbol table as an
export, but it cannot be interposed by another ELF module.
This option is required for user code to link properly to Qt, otherwise
they will get linker errors (assuming GNU binutils >= 2.39) or runtime
failures (glibc >= 2.35). Both versions of glibc and binutils are older
than GCC 12, so it's a safe assumption they are in use and downgrading
the toolchain or libc is not supported. Adding this option to the
compilation is assured for CMake and qmake-based projects.
For example, all accessess to QCoreApplication::self in QtCore, after
this change and with GCC 12 are relocation-free and direct:
000000000013ebf0 <QCoreApplicationPrivate::checkInstance(char const*)>:
13ebf0: cmpq $0x0,0x4f73d0(%rip) # 635fc8 <QCoreApplication::self>
13ebf8: setne %al
13ebfb: je a90fe <QCoreApplicationPrivate::checkInstance(char const*) [clone .cold]>
13ec01: ret
Meanwhile, accesses to the same variable in other modules are indirect
via the GOT:
66650: mov 0x876e1(%rip),%rax # edd38 <QCoreApplication::self@Qt_6>
66657: cmpq $0x0,(%rax)
This replaces the -Bsymbolic and -Bsymbolic-functions (broken)
functionality that Qt has been using or attempting to use since ~2006.
See https://gitlab.com/x86-psABIs/x86-64-ABI/-/issues/8#note_606975128
Change-Id: Iad4b0a3e5c06570b9f5f571b26ed564aa0811e47
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Set QMAKE_REPONSEFILE_THRESHOLD to 1 in the WebAssembly mkspec to
enforce the usage of linker response files. This fixes "The command
line is too long." errors when linking user projects that depend on many
libraries, for example projects using QtQuickControls2.
Pick-to: 6.2 6.3
Fixes: QTBUG-100559
Change-Id: I2f03f0756c9f171bc7382940fa0f8079bdb75a00
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Set QMAKE_CXXFLAGS_CXX2A variable to -std:c++20 while building projects
with qmake and MSVC 16.11 or greater (_MSC_FULL_VER >= 192930133), when
c++2a is specified in the project config.
Pick-to: 6.2 6.3
Change-Id: If9a48d1ed16cb05c5cc01414ce8a4344e22438fe
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
Implemented as an alias to keep c++2a working and remain consistent with
the way this was handled for the c++20 switch in cmake and the c++17
switch in qmake.
Pick-to: 6.2 6.3
Change-Id: I9a5f6d6b3a3adec748cf7207ceaa6da98d053cdb
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Hurd supports largefile, so enable it also in Qt.
Change-Id: I8384ca2cb5c6250376916b6a890e1a873c0a0e96
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
In release builds -olink also enables deletion of (unused) virtual
functions. In some cases this can lead to application crashes when
using loaders combined with timers. Prevent this by adding
-no_uvfd option to release build flags.
Task-number: QTBUG-99506
Pick-to: 6.3 6.2 5.15
Change-Id: I5c669e1e987f1fe912c9aca52ff82000125eed53
Reviewed-by: Tatiana Borisova <tatiana.borisova@qt.io>
Reviewed-by: Janne Koskinen <janne.p.koskinen@qt.io>
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Ville Voutilainen <ville.voutilainen@qt.io>
When trying to build qt3d examples with qmake and MinGW in the CI,
compilation would fail with errors like
In file included from
C:/MINGW1120/mingw64/x86_64-w64-mingw32/include/windows.h:72,
from C:\Users\qt\work\qt\qt3d\examples\qt3d\simple-cpp\main.cpp:63
include/winuser.h:2965:72: error: 'POINTER_INPUT_TYPE' was not
declared in this scope
What happens is that calling qmake on examples.pro loads
qt3d/.qmake.conf, which then loads qt_build_config.prf which then
defines the following definitions:
mingw: DEFINES += WINVER=0x0601 _WIN32_WINNT=0x0601
This limits usage of Windows API up to Windows 7, with later APIs
being unavailable.
Most .qmake.conf files were removed in qt repos, but We didn't remove
the .qmake.conf file (fb656c036d) for
qt3d because it's supposed to be buildable with CMake + Qt 6 as
well as qmake + Qt 5.
Bump the defines to the same Windows 10 version we use everywhere else
when building with CMake.
Amends 6652bf2353
Relates to d57a7c4171
Relates to fb656c036d
Pick-to: 6.2 6.3
Task-number: COIN-762
Task-number: QTBUG-92271
Change-Id: I833dfb6b0832d90a76d05ea14cd3807cb0d67ca9
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Emscripten now warns against passing e.g. “ALLOW_MEMORY_GROWTH”
as a compile option.
Add EMCC_THREAD_CFLAGS, which gets compiler flags only.
Pick-to: 6.3
Change-Id: Ifcf40c45ca75cfdfc98a12e6b9d47f34158b3407
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
Use “-pthreads” instead of “-s USE_PTHREADS=1”. This
is both a compile and linker option.
Pick-to: 6.3
Change-Id: Iaf7cb4ec41577fe596c3e81fda05c03fe0074c08
Reviewed-by: David Skoland <david.skoland@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
The “emterpreter” was the precursor to the current
asyncify support, but is not in use any more.
Pick-to: 6.3
Change-Id: I07ca04b61747e90939444525641b5aa34f7087b5
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
If Xcode wasn't configured with any simulators the build would fail
since we had no device to build for. But we don't need to build for
a specific device, we can build for the generic simulator device,
just like we do for the non-simulator build. This likely didn't
work properly at the time it was first implemented, but now seems
to work fine, and is less fragile than the current solution.
Running tests still enumerates the available simulators,
as that needs a concrete device to run on.
Fixes: COIN-777
Pick-to: 6.2 6.3 5.15
Change-Id: I50e31c1b350cf83ce348275b467051263dea88a9
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
-g4 was deprecated in Emscripten 2.0.17, and since we are well past
that version we can safely use -gsource-map instead.
Change-Id: I497155619d6320661f6be0e220b52fa7d6ca0b8e
Reviewed-by: David Skoland <david.skoland@qt.io>
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
[ChangeLog][wasm] Recommended emscripten version is now 3.0.0
Change-Id: I9ae082509415d8f00b8e9970b730ad4a472da310
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
When building a shared library (with qmake) in a user project
targeting Android, the library gets a QT_ARCH suffix added to its
name.
This suffix is not added when building a static library
(CONFIG += staticlib).
In the context of a multi-abi android qmake build, all the arch
specific static libraries would have the same name and would
override each other.
This happens with Qt 5.15 and it would also happen in Qt 6,
but we don't support multi-abi qmake builds in Qt 6 so far.
When the original fix to include the arch suffix for shared libraries
was done in Qt 5, d463a63bb9
it was likely an oversight that it was not applied to static
libraries as well.
The !static part of the condition was added in
72d4f0750b .
The change only handled installation responsibilities, not naming of
libraries.
Fix static libraries to include the arch suffix, but only in Qt 6.
It's too late to fix it in Qt 5, there might be projects that rely on
there not being a suffix in static library names. Adding the suffix
would suddenly cause linking errors.
Amends d463a63bb9
[ChangeLog][Android][qmake] Static libraries targeting Android will
now include an arch suffix when built using qmake.
Fixes: QTBUG-83165
Change-Id: I6f68dcb74cec30b4c8f0bc5a819d89843e9d695e
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Doc build is using the same variable to define the reponse file
as moc build, which can lead to case where moc is using the qdoc's
response file instead of its own. Moc needs more include paths than
qdoc, this can then lead to weird compilation issues as moc doesn't
warn about missing includes.
Task-number: QTBUG-98569
Pick-to: 6.2 5.15
Change-Id: Id35da18f664e2032bae96d11b00dbfe55ce37f66
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Large address aware is enabled by default in 64-bit
compilers, but not 32-bit compilers. But Qt users
may build 32-bit Qt themself, in this case large
address aware is disabled in fact, and it may cause
some issues. So we pass /LARGEADDRESSAWARE to the
linker unconditionally to make sure large address
aware is enabled for both 32-bit and 64-bit builds.
Microsoft Docs:
https://docs.microsoft.com/en-us/cpp/build/reference/largeaddressaware-handle-large-addresses?view=msvc-170
Change-Id: Idb2603d9ba0ba9ef4477ce1c3174b7c7e8ba76f6
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
We have some special handling in qt_windows.h,
use it instead of the original windows.h
Change-Id: I12fa45b09d3f2aad355573dce45861d7d28e1d77
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
To allow using Android 12 APIs.
Pick-to: 6.2 5.15
Change-Id: I5e9da66c84457888ec723125d16876891232a99b
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
...which represents the version of the MSVC platform toolset.
This variable is used to set the platform toolset version in .vcxproj
files. Before, the platform toolset version was determined in qmake's
C++ code. Now, it's set next to where MSVC_VER is set in common mkspecs
.conf files. This will simplify supporting new Visual Studio versions
in the future.
Change-Id: If78c921f93c6378829746d617c7e7d312174257e
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Extend the detection of the MSCV_VER variable and make VS 2022 known to
the vcxproj generator.
[ChangeLog][qmake] Added support for Visual Studio 2022.
Pick-to: 6.2 5.15
Fixes: QTBUG-97975
Change-Id: Id2c0a0b7800f721e9e34189f0a40ba4830283578
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
And bump NTDDI_VERSION to 0x0A00000B (NTDDI_WIN10_CO) at the same time,
to unblock the developers from accessing the latest Windows APIs.
Pick-to: 6.2
Change-Id: Ifbc28c8f8b073866871685c020301f5f20dc9591
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This breaks the build for qmake-based applications,
with the error
Project ERROR: Could not find feature sse2.
Remove the offending section to make applications
build again.
Pick-to: 6.2
Change-Id: I0b22faa1d8d62e208d79879b822e21637bb03a3e
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Emscripten only supports
SSE1, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, and 128-bit AVX instruction
sets at this time.
https://emscripten.org/docs/porting/simd.html
Browsers might need to enable simd support in the advanced
configurations
about: config or chrome:flags
Enable by configuring Qt with -sse2
Pick-to: 6.2
Fixes: QTBUG-63924
Change-Id: Ifeafae20e199dee0d19689802ad20fd0bd424ca7
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
qobject.h has #include <chrono>, which #includes <ctime>, which includes
<time.h>.
datetime.cpp:2621:23: error: 'localtime_r' was not declared in this scope; did you mean 'localtime_s'?
Pick-to: 6.2
Change-Id: I2bbf422288924c198645fffd16a922719c4ce7d4
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
A qmake project built for iOS-simulator tries to find suitable devices
in xcodebuild.mk.
If no suitable device could be found, the build failed with
xcodebuild: error: missing value for key 'id' of option 'Destination'
which isn't that helpful.
Detect the situation in xcodebuild.mk and print an error message.
Pick-to: 5.15 6.2
Fixes: QTBUG-77222
Change-Id: I02f9ab0dd7b8f234bcd8d0ea387927f31ca092e0
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
With single_android_abi, the file qmake_qmake_immediate.qrc is laid
directly into the root of the build dir and not under different abis
dirs.
Pick-to: 6.2.0 6.2 5.15
Fixes: QTBUG-87669
Fixes: QTBUG-95202
Fixes: QTBUG-95235
Change-Id: Ie13cccdf2fc323e8fd725a94f3aacab465fa1287
Reviewed-by: Andy Shaw <andy.shaw@qt.io>
It is no longer handled separately from Android.
This effectively reverts commit 6d50f746fe
Change-Id: Ic2d75b8c5a09895810913311ab2fe3355d4d2983
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
The following snippet in a .pro file resulted in a build error:
CONFIG += lrelease embed_translations
TRANSLATIONS += foo.bar_de.ts
The variable QM_FILES was incorrectly calculated. The extra compiler
that calls lrelease uses QMAKE_FILE_IN_BASE, which wraps
QFileInfo::completeBaseName(), resulting in "foo.bar_de.qm".
The $$replace call that calculates the .qm file name however, produces
"foo.qm".
Fix this mismatch by adjusting the regular expression to behave like
QFileInfo::completeBaseName().
Pick-to: 5.15 6.2
Fixes: QTBUG-79016
Change-Id: I545d1b58170cd5229007faf31c9b2c6f70ff75a6
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
If automatic signing is enabled (which it is by default), then Xcode will
happily set up the required profile if you open and run the application
in Xcode. To get the same behavior for xcodebuild, and hence from Creator,
since it's calling our Makefile wrapper around xcodebuild, we need to
pass the -allowProvisioningUpdates flag to xcodebuild.
Fixes: QTBUG-95565
Pick-to: 6.2 6.2.0 5.15
Change-Id: I9325bb228bdfb4d07658eff8f41798f7b5a6955c
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
By the time of Qt 6.2 release all new apps targeting Play store must
target API level 30 (Android 11) or above (starting in 08/2021 for
new apps and 11/2021 for existing apps' updates).
Pick-to: 6.2 5.15
Task-number: QTBUG-94451
Change-Id: Id7fa2fd62899a7259e365c917292c6c3ac0d2b0d
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
Add QEventDispatcherWasm to QtCore. The event dispatcher
supports managing event queue wakeups and timers, both
for the main thread or for secondary threads.
Blocking in processEvents() (using QEventLoop::WaitForMoreEvents)
is supported when running on a secondary thread, or
on the main thread when Qt is built with Emscripten’s
asyncify support.
Code is shared for all both modes as far as possible,
with breakout functions which handle main and secondary
thread as well as asyncify specifics,. Some functions
like wakeUp() can be called from any thread, and needs
to take the calling thread into consideration as well.
The current asyncify implementation in Emscripten is
restricted to one level of suspend, and this restriction
carries over to Qt as well. In practice this means we
support one level of exec()-like API.
Note that this commit does not _enable_ use of the
new event dispatcher. This will be done in separate
commits.
Task-number: QTBUG-76007
Task-number: QTBUG-64020
Change-Id: I77dc9ba34bcff59ef05dd23a46dbf1873cbe6780
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Make it possible to select the C17/C18 standard with
CONFIG += c17
or
CONFIG += c18
Pick-to: 6.2 5.15
Fixes: QTBUG-96026
Change-Id: I719d22366c3efda009118d58ead173a25ed285c0
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The compiler that comes with Visual Studio 16.8 added support for
setting the C11 standard with the /std:c11 flag.
Add the respective version check in msvc-version.conf and set
MSVC_VER and QMAKE_CFLAGS_C11 accordingly.
Pick-to: 6.2 5.15
Task-number: QTBUG-89296
Change-Id: I29b54ee073a765918f5aa4ebb081b97c5cf471d7
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Consider a release-only, non-framework Qt build on macOS. Building a
debug user project would fail, because qmake tried to link
against *_debug.dylib and *_debug.a libraries.
Building a debug user project that uses QtUiTools against a release-only
framework-build Qt posed the same problem. QMake tried to link against
the libQt5UiTools_debug.a, which does not exist.
Fix this by maintaining a list of library file candidates, and use the
first existing one (or just the first one if none exists). This favors
the library matching the user project's configuration but falls back to
the release version of the library if necessary.
Fixes: QTBUG-81251
Pick-to: 6.2
Change-Id: I8d641104718edb16500c6d6e3994e736fa5ddcf4
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
If QMAKE_APPLE_DEVICE_ARCHS is not set, we pick up the available archs
based on what Qt was built with (QT_ARCS), but only build the active
arch.
Pick-to: 6.2
Change-Id: I83273f878022af34a3a0d0eeae8b11d781f78c49
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Go with Emscripten’s default of not shutting down on
main() exit; this allows for writing main() in such
a way that avoids the exec() workaround.
Existing main() implementations (which do use the exec()
workaround) do not shut down Qt cleanly anyway, so we
gain little by shutting down the Emscripten runtime.
Applications can set this flag if they do want to shut
down on main() exit:
LFAGS += -s EXIT_RUNTIME=1
Change-Id: I52e1cc2bc907d1d2146822713e39b7610db3f95b
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
Make Emscripten generate a global constructor function
("createQtAppInstance()") instead of a global javascript
module object.
This enables more fine-grained control over module
instantiation; previously the module object would be
created when the runtime javascript was evaluated, and
the number of emscripten module/instances was limited
to one per page.
Set EXPORT_NAME to “createQtAppInstance” which avoids
collisions with other non-Qt Emscripten modules on
the same page. A further improvement would be to include
the app name in EXPORT_NAME, but this is not done at
this time.
Update the code in qtloader.js to call the constructor
function instead of working on a global module object.
The qtloader.js API is functional before the wasm and
Emscripten modules have been instantiated; store properties
and forward to the Emscripten module when it's created.
Change-Id: I12c49a5b9a4a932bbc46fcc5e5ecc453fd0fe7f0
Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
This fixes the "Command line is too long" error when building a project
with many object files for WASM on Windows.
Fixes: QTBUG-94032
Pick-to: 6.2 6.1 5.15
Change-Id: I29251da9795b267c968da86617da0311bf882a64
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
This reverts commit c686e885c0
and commit d64abf8166.
We don't feature .qmake.cache/.qmake.super files anymore in the
source directory, so there's no problem anymore.
Change-Id: Ib820a109fbfbad70d85b0f14ef72915882217ca3
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Now that inputs (81152194) and outputs (3f0858ed) are explicitly set for
the preprocess stage we can enable the new build system.
Using the legacy build system will produce a build error in Xcode 13,
but the build will succeed:
error: The Legacy Build System will be removed in a future release.
You can configure the selected build system and this deprecation
message in File > Project Settings.
Fixes: QTBUG-71035
Pick-to: 6.1 5.15 5.12
Change-Id: I108d2103872255d10de2ff5161eef892065da1c4
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
When dealing with a universal build of Qt, we would end up
using the QT_ARCH as the architecture for user projects,
but this architecture is always the primary one that Qt
was configured with.
Instead of relying on QT_ARCH, we start writing QT_ARCHS
(plural) to qconfig.pri, based on CMAKE_OSX_ARCHITECTURES,
and then use that to initialize QMAKE_APPLE_DEVICE_ARCHS.
We then resolve the active arch using uname -m, matching
what CMake does.
We still feed all the available architectures to the
Makefile or Xcode project, so that the user can build
for any of the available architectures without needing
a reconfigure.
Fixes: QTBUG-93760
Change-Id: I0d338241ba4d944ca36d85371e9c4df7dbc4f269
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This increases link time significantly; instead set
"-g4" or the new "-gsource-map" only if source maps
are enabled.
Change-Id: Ibe2d438d48e9ae2fce5f79d4e8a9f17c01cf2485
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
If we already have the list of Android ABI in BUILDS, it's not
necessary to generate extra resource while Qt build.
Amends: 58556afb69
Pick-to: 6.0
Pick-to: 6.1
Pick-to: 5.15
Fixes: QTBUG-88031
Change-Id: I344efe6c477461659a360281da59c4abeae18fc2
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Xcode's new build system checks duplicated entries when building. Qmake wants to embed
the launch screen for all types of configurations (static libraries etc.) which makes Xcode bail
out with "Multiple commands produce LaunchScreen.storyboard".
Pick-to: 6.0 6.1 5.15 5.12
Task-number: QTBUG-71035
Change-Id: I5c028e687f16e046b12156c1a8a89540deba4d3b
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Since we don't feature it for CMake, there's little point in keeping it
for qmake.
Pick-to: 6.1
Change-Id: I7f17d2536510c0b94dca9767036ceab7ec08e1d8
Reviewed-by: Tino Pyssysalo <tino.pyssysalo@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@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>
