If users have
CONFIG += qt
in their .pro file then the project won't link if the platform requires
the entrypoint module. This is because qt.prf is loaded before
entrypoint.prf in this situation.
Make the CONFIG values 'entrypoint' and 'qt' independent of their order
by embedding the content of entrypoint.prf into qt.prf.
Pick-to: 6.5 6.6
Fixes: QTBUG-117674
Change-Id: I72a3c9be023a73d70454533262544a4211cb6974
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
The new linker in Xcode 15 doesn't provide any default linker or
framework paths when requested via -v, but still seems to use the
default paths documented in the ld man page.
We trust that linker will do the right thing, even if we don't
know of its default linker paths.
We also need to opt out of the default fallback logic to
set the libdirs to /lib and /usr/lib.
This may result in UnixMakefileGenerator::findLibraries finding
different libraries than expected, if additional paths are
passed with -L, which will then take precedence for qmake,
even if the linker itself will use the library from the
SDK's default paths. This should hopefully not be an issue
in practice, as we don't turn -lFoo into absolute paths in
qmake, so the only risk is that we're picking up the wrong
prl files and adding additional dependencies that the lib
in the SDK doesn't have.
Pick-to: 6.6 6.6.0
Change-Id: I2347b26e2df0828471373b0e15b8c9089274c65d
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
The PRELOAD variable in wasm_shell.html wouldn't get substituted with
preload list when using qmake. Do that as it is done in cmake.
Fixes: QTBUG-115507
Change-Id: I3c659626dc6fa6f4fdf9e31bd62b87fc6a7d8bbe
Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
Reviewed-by: Piotr Wierciński <piotr.wiercinski@qt.io>
Previously, a target name with a JS special character (like, -, for
example), would lead to an invalid export name being generated for
WASM modules. Sanitize these by replacing any non-alphanumeric
character with underscores, as is done for feature names.
This is a qmake version of 58a47edda1
Fixes: QTBUG-115506
Change-Id: I7c84076be54da91cf0f707c1613afc382acdcb83
Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
Reviewed-by: Piotr Wierciński <piotr.wiercinski@qt.io>
Replace D-BUS with correct splling D-Bus in the source code,
Keep the old spelling inside XML DTD declarations for compatibility.
Change-Id: Ifa5d43f9fa1417431c81cf1bce0d897a966409b9
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The export name is now ${TARGET_NAME}Entry. This can also be overridden
by using QT_WASM_EXPORT_NAME, both in CMake and qmake
Change-Id: I59c97ae6e22f0b2720716e9d7eff7b6b13d37ab5
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
This is required when using the preload functionality
from qtloader.
Pick-to: 6.6
Change-Id: Ib1bf8788b87834ba0ff80d563897040e093a16b9
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Support for PRE_TARGETDEPS was added for iOS applications in
53ac8094b1, even if the Xcode
generator doesn't support PRE_TARGETDEPS, by taking advantage
of the glue Makefile we use to run xcodebuild.
And we add our own Qt libraries to PRE_TARGETDEPS in qt.prf,
as you would expect. But since Xcode supports both debug and
release, we always set debug_and_release for this glue Makefile.
The result is that when computing the Qt library PRE_TARGETDEPS,
we fail to apply a _debug suffix from qtPlatformTargetSuffix(),
since we've enabled debug_and_release.
In a debug only build, this means that 'make' of the glue Makefile
will fail to find the release versions of our Qt libraries.
To work around this we skip adding Qt to the target deps when
generating the xcodebuild Makefile, as we know these libraries
are added to the target in the Xcode project.
Pick-to: 6.5 6.2
Change-Id: Icafc103e34a6f83240fa8187181d885fb0172a86
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
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>
