x86_64 libs are located in ANDROID_PLATFORM_ROOT_PATH/usr/lib64
not in ANDROID_PLATFORM_ROOT_PATH/usr/lib .
Fixes: QTBUG-47672
Change-Id: Ia1f74f7c2a30b276b95fd0e7dcf8370d739e3c41
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>
Do not store this variable locally, because
a) it might change if the SDK location changes
b) does not play well with Qt installer packages which would provide the
include path of the build machine.
To achieve this we introduce the (usual) magic value - for
QMAKE_EXPORT_INCDIR_VULKAN to denote "do not export this value".
Fixes: QTBUG-73796
Change-Id: Ied26ee12cbcdf7f5f6e1caef5d29dadf6309c5d6
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
The sysrootification of QMAKE_INCDIR_OPENGL on macOS must happen only
once. Commit 49ef3773 addressed this but stored the sysrootified
QMAKE_INCDIR_OPENGL in qt_lib_gui_private.pri. For installer packages,
these paths are the paths of the build machine and most likely wrong
on the user's machine.
This reverts commit 4949ef377349ba4dae840c2d5caa36e2d516707baa and
restores the sysrootification in sdk.prf. The original include paths
are assigned to QMAKE_EXPORT_INCDIR_OPENGL and stored as
QMAKE_INCDIR_OPENGL in qt_lib_gui_private.pri.
Fixes: QTBUG-75374
Task-number: QTBUG-73736
Change-Id: I4c0f65866d60660c632363dba3adc7ea2e344bfc
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Avoid using inline assembler
Task-number: QTBUG-72716
Change-Id: I696efb5a787416eb4fc5ba3a250461aaa9a4afc2
Reviewed-by: Janne Koskinen <janne.p.koskinen@qt.io>
The sysrootification of OpenGL include paths must be done only once: at
configure time. The resolved paths are stored since 521a8539 and must not be
resolved again.
Turn the makeSpec-type opengl library into a custom-type one, and do
the sysrootification in the handler function.
Fixes: QTBUG-73736
Change-Id: I2933144057d6f01d8bfc7bda2c2df56c57303459
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Eirik Aavitsland <eirik.aavitsland@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
This reverts commit 37970d7b3e.
That commit broke the build on macOS, because the OpenGL headers aren't
resolved anymore at configure time.
Change-Id: Iec6ef009c9ea7e28b12eeca6b5eb06918bf49d98
Fixes: QTBUG-73827
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
Change-Id: I963fc1c159edc644f081675c3dee248c25d7c9dc
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Andre de la Rocha <andre.rocha@qt.io>
Since include paths are fully resolved, we must remove the code that prepends
the SDK path to the OpenGL include paths.
Change-Id: I80d74629c7fc989a89c3f1d95d6de43b4c1de17a
Fixes: QTBUG-73736
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Integrity assembler doesn't understand NEON assembly statements.
Compiler enables _ARM_NEON_ and _ARM_NEON to indicate that NEON
intrinsics are available. _ARM_NEON_ and _ARM_NEON needs to be
disabled to skip handwritten assembly code paths in Qt.Auto-
vectorization is enabled without the flags enabled.
Task-number: QTBUG-72716
Change-Id: I84cfbf98bd2af47740a79f4b300c1801017ee22c
Reviewed-by: Tuukka Turunen <tuukka.turunen@qt.io>
Reviewed-by: Kimmo Ollila <kimmo.ollila@qt.io>
Reviewed-by: Timo Aarnipuro <timo.aarnipuro@qt.io>
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
Qt couldn't be configured with -system-zlib on macOS, because qmake
failed to find "/usr/lib/libz.dylib".
The library path is something along the lines of
"/Applications/Xcode.app/.../MacOSX10.14.sdk/usr/lib" which doesn't
contain "libz.dylib". But it contains "libz.tbd", which is a YAML-file
pointing to "/usr/lib/libz.dylib". One can pass the absolute path to
this tbd file to the linker, which will then pick up
"/usr/lib/libz.dylib".
Introduce a new variable QMAKE_EXTENSIONS_AUX_SHLIB, which is a list
of auxiliary extensions for shared libs, and add the "tbd" extension
to it on macOS.
Change-Id: I083b79a69d00232e35f9d6164ffa86cb473f1742
Fixes: QTBUG-72745
Fixes: QTBUG-72964
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
fbbe8aba9d introduced a check for
MSVC_VER to qmake, which is not set in win32-clang-msvc,
causing the build to fail:
Mkspec does not specify MSVC_VER. Cannot continue.
Unable to generate output for: .../config.tests/verifyspec/Makefile
Extract a minimal msvc-based-version.conf which determines
MSVC_VER from QMAKE_MSC_VER for win32-clang-msvc and win32-icc.
Task-number: QTBUG-63512
Change-Id: Ia6de8c4b1aae2ae1962cf4e60e3e6d51fdbbbabe
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
amazingly enough, android has different sysroots for the compiler
(shared includes full of #ifdefs) and the linker (per-platform
libraries).
this patch supports only clang for non-darwin, which notably covers all
supported android ndks.
with this fixed, we also remove the hard-coded setting of
QMAKE_DEFAULT_*DIRS from the specs.
amends 353fb118c.
Change-Id: Ie0513de0f7123d7f5b8ca1ffcc72c017cddd126c
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Remove the option from msvc-desktop.conf, which duplicates
the /nologo option in idcidl.prf.
Fixes: QTBUG-72046
Change-Id: I906097e0611f4578c307616b3f9ebecdfc4d8812
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
there is no reason whatsoever to ignore the variable if it's set to an
invalid value. also, it being empty would lead to a warning from qmake
since a while.
so instead check it for emptiness like every other variable, not for
file existence.
Change-Id: I1119f67520d2986811501cd3f223f8f4a87d067d
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>
We need to support apps building against the 10.13 SDK, so that they
can opt out of dark mode and layer-backing. This does not mean we can't
require 10.14 to build Qt itself, but doing so should not require the
app to also build against the 10.14 SDK.
Change-Id: I53bd0fc8bf56c0be6614acec14d5173589e2620f
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
39cb9ac873 moved the _ENABLE_EXTENDED_ALIGNED_STORAGE define from
msvc-version.conf to msvc-desktop.conf which basically removed the
define from winrt builds. By adding it to winrt's common qmake.conf
these builds are fixed.
Change-Id: I3d87c55fb52685859713f7466012b45c46145678
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Move the definition of _ENABLE_EXTENDED_ALIGNED_STORAGE
to msvc-desktop.conf so that it becomes effective
for all compilers using MSVC (icc, clang-cl).
Task-number: QTBUG-50804
Change-Id: I5ff612cc0f5a712b855925f9bcf645e578e80504
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
As discussed earlier, we don't want to keep backwards compatibility
for more than two versions in addition to the current macOS version.
Change-Id: I24df6fb4a08e14a9f842d209b8e0a6079c533b65
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
Some distributions do not define MINGW_HAS_SECURE_API globally,
resulting in methods like wgetenv_s not being declared in the
headers.
This is probably to keep compatibility with Windows XP. Anyhow,
we don't support Windows XP anymore, so we can safely add the
define.
Note that this is not necessary for the mingw-builds distro,
which is the only one we test and support. Anyhow, I don't
see any risk in adding these for other distributions.
Diff was provided by Philippe Dunski in the bug report.
Task-number: QTBUG-67443
Change-Id: I3a64b11541fe95e527ed44bbf8ad94469d457d3d
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
As the comment says, Haswell is a nice divider and is a good
optimization target.
I'm using -march=core-avx2 instead of -march=haswell because the latter
form was only added to GCC 4.9 but we still support 4.7 and that has
support for AVX2.
This commit changes the AVX2-optimized code in QtGui to Haswell-
optimized instead. That means, for example, that qdrawhelper_avx2.cpp
can now use the FMA instructions.
Change-Id: If025d476890745368955fffd153129c1716ba006
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
By using -march= instead of -x, we turn on some other processor features
too. This was already the case for AVX2, which enabled all Haswell
features (notably FMA, BMI and BMI2).
Change-Id: If025d476890745368955fffd153126fc9eafc5d6
Reviewed-by: Alexander Shevchenko <sav_ix@ukr.net>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
linux-icc and macx-icc toolchains contain a significant amount of code
which can be merged to a common configuration file.
as a side effect, such merge resulted in reduction a parts of
linux-icc and macx-icc toolchains to the common view.
Change-Id: I37d110734eeeb9bd61ca0aa942de380ac8e75f1c
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This allows distinguishing between these tools and tools for the host,
when cross compiling.
While mac tools normally only are available on macOS, there are third
party efforts to port them to other platforms. In these cases, it
might be useful to use a prefix (either some sort of triplet prefix,
or an absolute path) to distinguish between the host build platform
compilers/tools and the ones for the cross target.
The use of this variable matches the one used in a lot of other
mkspecs, and shouldn't cause any issues for those who aren't setting
it.
Change-Id: Iaeba571d955ea79ed1249989fcc525eb1eaf1f5c
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
We need -Zc:__cplusplus in order to enable the __cplusplus macro having
the correct value. This causes configure to now print:
Checking for C++14 support... yes
Checking for C++1z support... yes
and
Using C++ standard ..................... C++1z
Change-Id: I5d0ee9389a794d80983efffd152c95a4d9d8adbc
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Add support for QSurface::VulkanSurface and QVulkanWindow.
Usage:
1) Build MoltenVK according to instructions
2) Configure Qt: ./configure -I /path/to/MoltenVK/Package/Release/MoltenVK/include
3) export QT_VULKAN_LIB=/path/to/MoltenVK/Package/Release/MoltenVK/macOS/libMoltenVK.
Implement support for QSurface::VulkanSurface by enabling
layer mode for QNSView and then creating a CAMetalLayer,
which the MoltenVK translation layer can run on.
MoltenVK provides an implementation of the Vulcan API,
which means that the platform integration is similar
to other platforms: implement a QCocoaVulkanInstance
where we pass the QNSView instance to the vkCreateMacOSSurfaceMVK
Vulkan surface constructor function.
Using Vulkan directly without QVulkanWindow is possible, but not
tested.
We currently load libMoltenVK at run-time and use the
existing QT_VULKAN_LIB environment variable to set its
path. For deployment purposes it would be better to
link against MoltenVK.frameworkm, but this
Task-number: QTBUG-66966
Change-Id: I04ec6289c40b199dca9fed32902b5d2ad4e9c030
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
Add qmake feature and configure option, which optimze the size of static
exectuable. Use for static build.
Enabled via configure --gc-binaries, or CONFIG += gc-binaries in 3rd party
projects.
Change-Id: I3c25b02caaef6a4afc6019afc9c67122dd11696d
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Fixes the default C version used with gcc < 5
Change-Id: I948dece961caed8e6b181e1c6e6b9dc43c46583e
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
The android mkspecs had their own way of doing the same as optimize_size
Change-Id: Id05822df6bdeb8b3aafada2901bd61530c490fe9
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: BogDan Vatra <bogdan@kdab.com>
Some mkspecs do not support c++ strict mode.
We should allow them to build Qt with GNU extenstions.
Change-Id: I0d76cf95355b38953e3475773ec5474c856e1370
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
The change causes a crash when compiling the xkbcommon 3rdparty
library and compile failures (qtimageformats on Android).
This reverts commit a47cb14680.
Task-number: QTBUG-67326
Task-number: QTBUG-67327
Change-Id: I5ddc4eccad699e3eaec535fd6a63d11b0026b42e
Reviewed-by: Sami Nurmenniemi <sami.nurmenniemi@qt.io>
Reviewed-by: Liang Qi <liang.qi@qt.io>
Reviewed-by: Gatis Paeglis <gatis.paeglis@qt.io>
Fixes the default C version used with gcc < 5
Change-Id: I948dece961caed8e6b181e1c6e6b9dc43c46583f
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
When QFile::open is called with the NewOnly flag, the call will
fail if the file already exists. As usual, if the file does not exist,
it will be created. Like QTemporaryFile, there is a guarantee from
the operating system that you are not accidentally creating a new file
on top of an older file. When QFile::open is called with the
ExistingOnly flag, the call will fail if the file does not exist. The
ExistingOnly flag only provides new functionality when used with the
WriteOnly flag. For ReadOnly it provides no change in functionality,
as ReadOnly by itself already never creates.
Task-number: QTBUG-52244
Change-Id: I8e3206728f245f95172c225bf297023fb078fc6d
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
mingw-w64 toolchain:
- add missing compiler definitions, similar to
'msvc-desktop.conf' toolchain,
- describe the reasons of missing compiler definitions, available in
'msvc-desktop.conf' toolchain,
- add missing 'QMAKE_CXXFLAGS' and 'QMAKE_CXXFLAGS_WARN_ON' variables,
similar to 'msvc-desktop.conf' toolchain.
ICC on Windows toolchain:
- add 'QMAKE_CFLAGS_OPTIMIZE_FULL' variable, similar to 'gcc-base.conf'
toolchain, though left it unused for now,
- add missing flags to 'QMAKE_CFLAGS' variable, similar to
'msvc-desktop.conf' toolchain,
- update deprecated 'Qwd' flag with 'Qdiag-disable',
- use 'QMAKE_CFLAGS_OPTIMIZE_DEBUG' variable instead of '-Od' flag,
similar to 'gcc-base.conf' toolchain (ICC implies '-O2' optimization
level by default, while MSVC implies '-Od'),
- add 'QMAKE_CFLAGS_UTF8_SOURCE' variable, similar to
'msvc-version.conf' toolchain; use a workaround to initialize it,
until '-utf-8' flag would be supported by ICC on Windows,
- update deprecated '-Qstd=c++1z' flag with '-Qstd=c++17',
MSVC toolchain:
- remove 'incremental' from MSVC 'CONFIG' variable, since it has
relevance only for the Unix generator,
- add 'QMAKE_CFLAGS_OPTIMIZE_DEBUG' variable, used in ICC for Windows
toolchain,
- add empty 'QMAKE_LIBS' variable, similar to 'win32-g++' toolchain,
- add 'uuid.lib' library to 'QMAKE_LIBS_GUI' variable, similar to
'win32-g++' toolchain,
- add C++14 and C++17 language support flags, though left them disabled
for now, similar to 'win32-icc' toolchain.
Change-Id: Ideef62d0422674184836faa655bfc5d09a5f612f
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Common changes to mingw-w64, ICC on Windows, and MSVC toolchains:
- set similar order of variables and its splitting into sections,
- set similar order of flags in variables and the way they are set.
mingw-w64 toolchain:
- move 'gcc-base.conf' include before setting Windows specific
flags, similar to include 'msvc-desktop.conf' in ICC on Windows
toolchain; this leads to consistency with other toolchains
and allows to safely override common GCC variables with Windows
specific ones, when needed,
- move 'QMAKE_EXT_OBJ' and 'QMAKE_EXT_RES' variables to the linker
flags section, according to its purpose.
MSVC toolchain:
- set flags order in 'CONFIG' variable, similar to mingw-w64 toolchain.
Change-Id: I417cc8f7959c669dd504f2c5c11eb879a7989bd4
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
