If RESOURCES contained a non-existent .qrc file, qmake produced
Makefiles that resulted in an infinite loop when running GNU Make.
Introduce a new extra compiler CONFIG value "remove_no_exist" that
removes non-existent extra compiler input. This value is now used in the
extra compiler that handles the RESOURCES variable.
The difference to the existing CONFIG value "ignore_no_exist" is that
qmake still prints a warning about the non-existent file.
Pick-to: 6.5
Fixes: QTBUG-112743
Change-Id: I3293af75b75f217e1a1738b49da0af1117cfdecb
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>
The qtPlatformTargetSuffix() function is used in various places to
determine the suffix of targets based on the config, which for macOS
will result in a _debug suffix in debug mode.
This becomes tricky when one project built in debug mode tries to depend
on the libraries/plugins of another project (Qt) built in release, as
the qtPlatformTargetSuffix() function uses the current CONFIG as input,
which may be different than the QT_CONFIG (or CONFIG of whatever project
is being depended on).
For libraries this was fixed in 50e664835b
by iterating all known library paths, and trying the CONFIG suffix before
falling back to release version.
For plugins this was never solved, which becomes an issue when linking
to static plugins, either in a fully static build of Qt, or when some
of the plugins are static (permission plugins e.g.).
In this situation, the user project has to have the same configuration
as Qt was built with, to avoid errors like:
error: no such file or directory: '~/6.x-static/qtbase/plugins/platforms/libqcocoa_debug.a'
To work around this, we assume that a plugin installed into the Qt
tree has the same build configuration as Qt itself, then then use
QT_CONFIG as the determining factor when linking to the plugin.
This still ties the build config of the plugin to the config of Qt,
but relaxes the relationship to the application, allowing it to be
built in either debug or release, which is an improvement to the
current state.
Pick-to: 6.5 6.5.0
Task-number: QTBUG-110356
Change-Id: Icee67fc01313a6c6f34178a6345ccae1b57429d7
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Repeating the body of the reported bug, "Building Qt modules with qmake
is unsupported in Qt6 and since 6.5's switch to syncqt.cpp broken."
[ChangeLog][qmake] Support for building Qt modules with qmake was
removed.
Pick-to: 6.5
Fixes: QTBUG-110134
Change-Id: Iee5aa5c85f7106bce742df448ec502e6cc039454
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Few tweaks:
- Remove extra closing parenthesis
- Use absolute paths as the exists() checks & other plist path
uses are relative to the permissions.prf location
- Use the plist path with PlistBuddy instead of the variable
from .pro file
Pick-to: 6.5
Change-Id: I27c7f1e7044a55ff7fbd78ef1dd79c92b17e8018
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
This reverts commit d7e8d5bb1b.
Reason for revert: Found a working solution for the issue.
Change-Id: Ia720cc63ece9dfb1a24067cdd9c3d79d4edbe3be
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
Right now, "multi abi builds" of android projects works only if the
android-build installation doesn't use custom install dirs
(INSTALL_PREFIX, INSTALL_BINDIR...)
At the same time, it fixes QTBUG-106533. The patches are the same as the
ones in that bugreport.
Add new items to android-*-deployment-settings.json:
qtDataDirectory
qtLibsDirectory
qtLibExecsDirectory
qtPluginsDirectory
qtQmlDirectory
Update androiddeployqt to be able to get files from their install location
BTW (fixes QTBUG-106533):
Install src/android/templates into INSTALL_DATADIR
Install src/3rdparty/gradle into INSTALL_DATADIR
Install src/android/java files into INSTALL_DATADIR
Install all jars into INSTALL_DATADIR
Add missing path to target_qt.conf
Update target_qt.conf to have all path. Otherwise qmake wouldn't have
the path when installing the android-build with custom install dirs
like INSTALL_LIBDIR & friends
Add support for a new cmake variable that can be set at build time of the
android projects: QT_ANDROID_PATH_CMAKE_DIR_${abi} (Name chosen as
brother of QT_HOST_PATH_CMAKE_DIR)
Pick-to: 6.5
Fixes: QTBUG-106533
Fixes: QTBUG-107207
Change-Id: Ia3751362ab1b5f877ecafbe02f263feac167119c
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Otherwise we might conclude that we found a usage description when
PlistBuddy outputs "Error Reading File: /tmp/Info.plist" to stdout.
For CMake this is not an issue as we pipe stderr to a separate variable,
that contains "Cannot parse a NULL or zero-length data" in this case.
Fixes: QTBUG-109967
Pick-to: 6.5
Change-Id: I9d819b6de405b88bb7d1d75c22b6f5187f26e553
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Qt 6.5 will require emscripten 3.1.25. This is not the
most recent version (3.1.27 at the time of writing),
however .26 and .27 make changes to stack layout and size
which require further investigation.
Change-Id: Ibe285ef160d450d6b2c63a7fb71d3561b0032e37
Reviewed-by: Aleksandr Reviakin <aleksandr.reviakin@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
The values should come from android-clang mkspecs. The hardcoded
values don't work correctly with recent Android NDKs.
Pick-to: 6.4 6.2 5.15
Fixes: QTBUG-108662
Change-Id: Ie153a50ee0c49bd4f0704b588a4e2c87a05c1063
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
When submitting applications to the iOS and macOS AppStore the
application goes through static analysis, which will trigger on
uses of various privacy protected APIs, unless the application
has a corresponding usage description for the permission in the
Info.plist file. This applies even if the application never
requests the given permission, but just links to a Qt library
that has the offending symbols or library dependencies.
To ensure that the application does not have to add usage
descriptions to their Info.plist for permissions they never
plan to use we split up the various permission implementations
into small static libraries that register with the Qt plugin
mechanism as permission backends. We can then inspect the
application's Info.plist at configure time and only add the
relevant static permission libraries.
Furthermore, since some permissions can be checked without any
usage description, we allow the implementation to be split up
into two separate translation units. By putting the request in
its own translation unit we can selectively include it during
linking by telling the linker to look for a special symbol.
This is useful for libraries such as Qt Multimedia who would
like to check the current permission status, but without
needing to request any permission of its own.
Done-with: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Change-Id: Ic2a43e1a0c45a91df6101020639f473ffd9454cc
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
If Qml module is not found it doesn't make sense to run any
functionality that is related to Qml inside androiddeployqt. Add the
deployment setting option that indicates this explicitly and set it
to true when Qml module is not found by CMake or by qmake.
Task-number: QTBUG-106939
Pick-to: 6.4 6.2
Change-Id: I1e6cffbdd230007feffe7448617097c10238a6c9
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
I noticed that the QtCore version file had several entries for
13QObjectPrivate, which turns out to be for all the nested structs
inside. That's not harmful for QObjectPrivate, since that is itself a
private, but would be a problem for a nested struct of a public class.
I'm sure those exist.
Pick-to: 6.4
Change-Id: Ic6547f8247454b47baa8fffd170ea79360aaa615
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Unexported structs do mark private API too. This change necessitated fixing
the negative-lookahead, because otherwise we'd match a line like:
class QVariant;
With $1 = "QVarian" and the "t" stood for the negative lookahead.
Pick-to: 6.4
Change-Id: Ic6547f8247454b47baa8fffd170bba2c68c29dbc
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Unify the settings for single-threaded and multi-threaded builds;
Qt now always enables heap growth by default.
This means we don't have to reserve a large (1GB) fixed memory
size, but can instead set the smaller (50 MB) initial memory size,
like the single-threaded build does.
Enabling threads + memory growth can potentially cause
a performance regression when accessing heap memory from
JavaScript (https://github.com/WebAssembly/design/issues/1271).
We leave it for the application to decide if this applies,
and if the switch to fixed memory should be made.
Change-Id: I96988b072506456685086e55aca4007a146bd70f
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Mikołaj Boc <Mikolaj.Boc@qt.io>
Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
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>
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>
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 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>
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>
...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>
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>
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>
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>
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>
