We normally override the entrypoint to _qt_main_wrapper via the -e flag
to the linker, but if a Swift file is added to the Xcode project, Xcode
does some magic, building the app as a shared library, and wrapping it
with the Swift code into a custom executable. The -e flag will then be
a noop when linking our shared library.
To work around this we set the custom LD_ENTRY_POINT Xcode build setting,
which triggers Xcode to pass -e when linking the wrapper-executable.
This works in practice, but produces a warning on the console that the
entrypoint is not found, which has been reported as FB16519113.
Fixes: QTBUG-133577
Change-Id: I9d8310b39ac5a4900693df55c2e5bfa346c0300a
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
(cherry picked from commit 430ba7c0f826ee6f91fbfdc861525cb62b8e725c)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
(cherry picked from commit 9fbb8e0090a1d8220479e776feae7c9c5bb8493e)
According to the discussion in QTBUG-132398, the script stopped
working in newer Xcode versions, and also didn't cover new
Objective-C language features.
Remove the script to avoid confusion.
Fixes: QTBUG-132398
Change-Id: I37b96ac6a77af1fcc4221591cb1f6320fa9a024b
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
(cherry picked from commit 6404714183b3fcf93ac27482c5a3193a4f93767d)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
(cherry picked from commit 5165a8bacc3050d465d065a13271e15df229ea6c)
On Apple platforms we no longer _debug suffix libraries (and plugins)
in single config framework builds. This is a follow-up for logic in
qmake that didn't get adjusted in d3be87ff1d558f05309b1f29f7e71f291498584f.
Change-Id: I6461fca9da5c3ac1382ffc46e63409ef0150ad46
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
(cherry picked from commit 20d89a2710488ca5f9f6674c4c6d167f3a193383)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
To allow using Android 14 APIs, this affects only Java
code.
Amends 7b84cd62b0.
Change-Id: Ie79df773499976ba5c847be98ff5d21ee55036e9
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Qt already runs on Vision Pro as "Designed for iPad", using Qt
for iOS. This change enables building Qt for visionOS directly,
which opens the door to visionOS specific APIs and use-cases
such as volumes and immersive spaces.
The platform removes some APIs we depend on, notably UIScreen,
so some code paths have been disabled or mocked to get something
up and running.
As our current window management approach on UIKit platforms
depends on UIWindow and UIScreen there is currently no way to
bring up QWindows. This will improve once we refactor our
window management to use window scenes.
To configure for visionOS, pass -platform macx-visionos-clang,
and optionally add -sdk xrsimulator to build for the simulator.
Change-Id: I4eda55fc3fd06e12d30a188928487cf68940ee07
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Xcode expects the base SDK to always be the device SDK, so we can't
pass QMAKE_MAC_SDK on directly.
We use the Xcode SUPPORTED_PLATFORMS setting to inform Xcode about
which targets we can actually build and run for.
Change-Id: I32f474a9f2016fb410225cfef1fecc6598ac6c82
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
According to QUIP-18 [1], all tools file should be
LicenseRef-Qt-Commercial OR GPL-3.0-only WITH Qt-GPL-exception-1.0
[1]: https://contribute.qt-project.org/quips/18
Pick-to: 6.7
Task-number: QTBUG-121787
Change-Id: Icd5d5be2e04819617e68ff142924de1773bebbad
Reviewed-by: Kai Köhne <kai.koehne@qt.io>
According to QUIP-18 [1], all build system files
should be BSD-3-Clause.
The files in this patch are part of the build system.
[1]: https://contribute.qt-project.org/quips/18
Pick-to: 6.7
Task-number: QTBUG-121787
Change-Id: I9a79fb04971b117515ed16b3978435ad8ef0e31f
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
This increases the maximum available memory from 2GB
(Emscritpten default) to 4GB, which is the 32-bit wasm
max.
Add QT_WASM_MAXIMUM_MEMORY qmake/cmake option for overriding.
Pick-to: 6.7
Change-Id: I6257fc919a749412c4ba1e0f939996c6057ce314
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
If there's e.g. an infinite loop during main() that
would previously result in a blank page, but not error
message. The expected case is that we would get a RangeError
exception, but that exception never reaches the catch
handlers in qtloader.js.
Work around this by setting noInitialRun, followed by
calling main manually. We then need to handle the case
where the app.exec() workaround throws, which should
not trigger an error.
Pick-to: 6.7
Change-Id: Ia8431279308770981316cd168e4316341bfb2531
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
The warnings are shown when configuring any Qt submodule or top-level.
The warnings are NOT shown when configuring a user project with CMake.
Opt out CMake cache variables can be set to silence any of the
warnings:
- QT_NO_APPLE_SDK_AND_XCODE_CHECK
- QT_NO_APPLE_SDK_MIN_VERSION_CHECK
- QT_NO_XCODE_MIN_VERSION_CHECK
- QT_NO_APPLE_SDK_MAX_VERSION_CHECK
The warnings can be upgraded into errors by configuring with
-DQT_FORCE_FATAL_APPLE_SDK_AND_XCODE_CHECK=ON
The platform version requirements that qtbase specifies in .cmake.conf
are saved in Qt6ConfigExtras.cmake so that they can be used when
configuring other non-qtbase submodules.
The code is added to the public CMake files, so that in the future we
don't need to move code around if we enable the checks for public
CMake projects as well.
The version extraction helpers were moved out of QtAutoDetectHelpers
into QtPublicAppleHelpers.
Task-number: QTBUG-119490
Change-Id: Ic840e1013aeb607bf23247a9cb43471dde802e9d
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Amir Masoud Abdol <amir.abdol@qt.io>
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>
Tor Arne Vestbø
Alexandru Croitor
Piotr Wierciński
Assam Boudjelthia
Lucie Gérard
Lorn Potter
Morten Sørvig
Joerg Bornemann
Mikolaj Boc
Ievgenii Meshcheriakov
Thiago Macieira
Amir Masoud Abdol
Juha Vuolle
Alexey Edelev
Fab Stz
Timur Pocheptsov