Let's not allow any new code that uses non-conforming syntaxes. With
GCC and like, we already use -std=c++11 instead of -std=gnu++11 for that
very reason.
Change-Id: I4a7dc1fe14154695b968fffd14aba9f8cea69c47
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Neither the Intel compiler nor Visual C++ have a dedicated switch to
enable F16C support, like GCC and Clang do. So we used the AVX switch
for that in commit 8241d51f70, as it was
the closest, lowest denominator. That was incorrect and insufficient.
The Intel compiler silently miscompiles the intrinsics with -xAVX,
making calls to out-of-line functions like _mm_cvtps_ph, which don't
exist. So we actually have to use AVX2 support to generate correct code.
That might be a problem later, since Ivy Bridge supports F16C but not
AVX2.
Visual C++ is able to generate F16C code with just -arch:AVX.
Either way, since there's no dedicated command-line switch, there's also
no dedicated preprocessor macro. We're using __AVX2__ for both
compilers, as that's a sufficient condition to indicate a processor that
supports F16C.
Change-Id: I27b55fdf514247549455fffd14b205b8d8b86da7
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
Use F16C or ARM FP16 if available at compile time.
Configure check added because older clang compilers have F16C defines
and flags but not all the intrinsics.
Change-Id: I71f358b8fd003e70ab8fcf35097414591e485112
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This is an old error of the gstrip binutils. The bug has been corrected
and re-introduced.
The command *elfdump -d xxx* on the ELF does bring lines like those :
.SUNW_syminfo: invalid sh_info: 0
Task-number: QTBUG-58814
Change-Id: I330c4031dcf4ba64297df4b333b41cf0a003914f
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
The path match OpenIndiana distribution based on Illumos.
Task-number: QTBUG-56293
Change-Id: I44e7defa63809dc4f413b46329481b53e5e74c30
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Use of gcc-base.conf, g++-base.conf files and creation of solaris.conf.
The content of solaris.conf should follow the content of linux.conf.
Task-number: QTBUG-56293
Change-Id: I59cf9efa82ab0a2b22ea1a58f6339280460e5f92
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Building qt with msvc would fail with the -developer-build configure
option turned on under simplified chinese locale.
This is because msvc will emit warnings for source files with utf-8
characters which are not representable in CP936, and -developer-build
implies treating warnings as errors.
This patch turn on -utf-8 compiler option for msvc2015 update 2
and up only for building qt.
Task-number: QTBUG-58161
Change-Id: If38ea11eb1f39f8e08efa1cccb92e0eea50daf92
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
The uvfd flag is implicitly defined when -Olink is used.
This causes the compiler to generate a warning for every
file being compiled in release mode.
Change-Id: I75759151864da7cf2f6d9c812e466a52c1208444
Reviewed-by: Nikola Velinov <nvelinov@ghs.com>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
The patch fixes a number of bugs in code, and removes dead logic
clarifying that MIPS DSP, like ARM NEON, has no runtime detecton.
Change-Id: If2f4eea68da5b2eaa80b8e9c8258206d8c1b7173
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Enables optimizing with -Og if GCC has the option available, this
should produce faster debug binaries without compromising debugability.
Is a privateConfig to limit it to the default Qt build.
Includes two fixes for false positives of maybe_uninitialized triggered
by -Og on gcc 4.9.
Change-Id: I466d7a4070295714189024369312e6cbd36cfacf
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
This was used solely for building freetype. It was made obsolete as of
2eaf0cf8fd which upgraded freetype to a
newer version which does not rely on that define, first included in 5.5.
Change-Id: Iaaea8d6783032d784f0a370f8404972967fa7a06
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
[ChangeLog][QtBase][General] Removed support for WinRT/Windows Phone 8.1.
Task-number: QTBUG-57288
Change-Id: Ifd6d6780cbbdb710d99556ba3d2fb2e514d4f789
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Initial support for INTEGRITY to build QtBase
Change-Id: I18f36b4dea9107f01e1c281e4b62880590c777a1
Reviewed-by: Tuukka Turunen <tuukka.turunen@theqtcompany.com>
Reviewed-by: Nikola Velinov <nvelinov@ghs.com>
Reviewed-by: Risto Avila <risto.avila@qt.io>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
this is mostly for appearances (as evidenced by everything working
despite it being missing from some specs), as the variable is just a
fallback for moc.prf's automatic detection.
Change-Id: Ie4af24c02ec03aaa1810281d1bb6876ea38cedf8
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
Since we can tell the MSVC version from the compiler now, each of the
qmake.conf files is now the same, so let's just have "win32-msvc" and be
future-proof. Likewise for win32-clang-msvc.
qplatformdefs.h was already common.
Since we can't obtain the MSVC version from the unified mkspec name any
more, I dropped the warning level during the qmake bootstrap to reduce
the number of warnings that need to be disabled from compiler version to
version.
There is no point in keeping the old mkspecs, but configure will re-map
the -platform argument to the unified spec as necessary, to keep
existing configure command lines working.
[ChangeLog][Visual Studio] Qt now has a common mkspec for all Visual
Studio versions, called "win32-msvc". The old names which contained the
version number are now gone (but qmake scopes based on the old names
continue to work). The version of the compiler can be obtained from the
MSC_VER and MSVC_VER variables (for example, for Visual Studio 2015,
those contain the values 1900 and 14.0, respectively). Those variables
are also available with the Intel compiler (win32-icc) and with Clang
(win32-clang-msvc).
Done-with: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Change-Id: Ib57b52598e2f452985e9fffd14587c0a77a5c09c
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
We're asking the compiler anyway, so we can fully use this information
just as well. Note that this actually happens after the spec itself has
been processed, so it was necessary to delay the version-specific flag
handling as well.
Change-Id: Ib57b52598e2f452985e9fffd14587b581d946022
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
this makes it consistent with the determination of the default
include/library paths. this makes sense, as it's possible to switch the
sdk/toolchain after building qt (within reason).
a side effect of this change is that for compilers which emulate other
compilers, both the real and the emulated version are now made
available.
Change-Id: Icfcc672c0d2e3d1b5e622993c366063d70ad327c
Started-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
This is needed in order to be able to specify a custom location of
the ANGLE libs, and enables us to perform a LoadLibrary of ANGLE libs
by just having the absolute path to QtANGLE.dll as the argument to
LoadLibrary().
Previously, we had two ANGLE libraries: libEGL and libGLESv2. libEGL hard
linked against libGLESv2. If we wanted to load libEGL from a custom
location, we couldn't load libEGL by calling LoadLibrary with the absolute
path to libEGL, because libEGL had problems finding libGLESv2. One
solution to that could have been to call SetDllDirectory() with the path
to the ANGLE libs before calling LoadLibrary("libEGL.dll"). Since the DLL
directory would point to both ANGLE libs, this would ensure that the libGLESv2
was also found. Unfortunately, this approach is not thread safe
(SetDllDirectory will affect all subsequent LoadLibrary(Ex) from the same
process). Therefore, we chose to merge the two libraries into one to
circumvent the whole problem.
At the same time, this patch also enables loading of two different ANGLE
libraries into the same process at once without renaming them: This was
not possible before because libEGL hard linked to libGLESv2.dll. When
libGLESv2.dll was already loaded, the second instance of libEGL would
simply link against the already loaded version of libGLESv2.dll.
This behavior is documented in the LoadLibraryEx documentation on MSDN:
"If the string specifies a module name without a path and more than one
loaded module has the same base name and extension, the function returns a
handle to the module that was loaded first."
Change-Id: Ic1d886ba802be72ddcf01235bafaedcef662762e
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Jan Arve Sæther <jan-arve.saether@theqtcompany.com>
This scheme is needed to define Bluetooth (LE) capabilities on Windows
Phone 8.1. Setting these capabilities is a bit more involved than what
we currently support from qmake (see
https://msdn.microsoft.com/library/windows/apps/dn263090.aspx) but this
way we at least prepare the template for these steps.
On Windows 10 the bluetooth capabilities are set automatically similar
to the way it happens for other modules.
Change-Id: Ib3aa88802c3b421c9c3d02ec4db647cde2191f16
Reviewed-by: Maurice Kalinowski <maurice.kalinowski@qt.io>
Split them and add -I flags to INCLUDEPATH and -D flags to
DEFINES. Anything else gets reported as a problem and dropped.
This has the benefit that qmake will automatically use -isystem for
those paths if they lie in a system directory. As a consequence of that,
we won't get any warnings in headers located there. There are multiple
cases of glib, gtk, etc. headers producing warnings (such as enums
ending in comma). This does not fix warnings produced by use of macros
declared in system headers, though...
Done-with: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Change-Id: I4b844cb518dbae5ea499811221f9015af985110a
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
This is now centralized in configure.pri except where it explicitly
needs to be overridden.
Change-Id: If829d6b5eecf9a5fc403d0a0600d12c9e5781525
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
There's no reason for this to be separated, regardless of the
support status of i386 macOS builds. Additional architectures may
appear in the future (and currently there's actually 3 - i386,
x86_64, and x86_64h for Haswell CPUs). So this feature could be
used to get combined generic x86_64 and Haswell builds. Some
system libraries appear to have an x86_64h slice in Sierra.
[ChangeLog][Build System] Support for universal binaries on macOS
has been re-introduced.
Change-Id: I1c89904addf024431fdb3ad03ea8ab85da7240ad
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
This essentially emulates Xcode behavior for QMAKE_BUNDLE_DATA.
This is mostly for our own internal use. No documentation is provided.
Variables introduced:
- QMAKE_ASSET_CATALOGS
- QMAKE_ASSET_CATALOGS_APP_ICON
- QMAKE_ASSET_CATALOGS_BUILD_PATH
- QMAKE_ASSET_CATALOGS_INSTALL_PATH
Change-Id: I9577415d637f022d05f301c5a0d799483cd2a963
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
the code got factored out to an own toolchain.prf file, which is
load()ed from default_pre.prf, so no change at first.
however, on mac, we shadow toolchain.prf, and make it load() sdk.prf
first.
a side effect of this is that project files may not override
QMAKE_MAC_SDK any more, which seems to be no big loss. it is still
possible to override the sdk on the configure command line (but note
that this only ever worked for the target sdk).
it has also become harder to disable the use of an sdk altogether:
putting CONFIG-=sdk into a project file or the qmake command line has no
effect now. instead, it's possible to put it into .qmake.{conf,cache}.
to make it simpler again, it's conceivable to finally add qmake -pre,
which would allow setting variables before default_pre.prf is executed.
Change-Id: I149e0540c00745fe8119fffd146283bb214f22ec
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
... to the new qmake based configuration system.
This removes the old qfeatures.txt (distributed over configure.json
files) and qfeatures.h (distributed over qconfig-<module>.h files).
qfeatures.prf is gone without replacement, as attempts to use it would
lead to followup errors anyway.
Change-Id: I1598de19db937082283a905b9592d3849d2199d0
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Actually enables headerpad_max_install_names in the darwin-g++ mkspec
as previously it was (presumably accidentally) cleared.
Change-Id: I4b2e5a0dcf38658cfe35bc0e5f24769c80f4d877
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Now QMAKE_RPATHDIR also includes @executable_path and @loader_path
on Apple platforms, and omits any others on iOS, tvOS, and watchOS
since they can't use paths outside the application bundle.
Change-Id: Ia8f76ebcddd51f44eca482a51ce1710369c8df10
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
cf53aa21bf and 3aaa5d6b32
were reverted because of reconstruction in 5.7.
defineTest(qtConfTest_checkCompiler) in configure.pri is smart
enough to cover the case in a9474d1260.
DirectWrite: Fix advances being scaled to 0
Since 131eee5cd, the stretch of a font can be 0, meaning
"whatever the font provides". In combination with ec7fee96,
this would cause advances in the DirectWrite engine to be scaled to
0, causing the QRawFont test to fail.
Conflicts:
configure
mkspecs/features/uikit/device_destinations.sh
mkspecs/features/uikit/xcodebuild.mk
src/corelib/global/qglobal.cpp
src/corelib/global/qnamespace.qdoc
src/plugins/platforms/cocoa/qcocoamenuitem.h
src/plugins/platforms/windows/qwindowsservices.cpp
src/plugins/platformthemes/gtk3/qgtk3dialoghelpers.cpp
src/plugins/platforms/windows/qwindowsfontenginedirectwrite.cpp
src/widgets/kernel/qapplication.cpp
tests/auto/widgets/dialogs/qfiledialog/tst_qfiledialog.cpp
tests/auto/widgets/dialogs/qfiledialog2/tst_qfiledialog2.cpp
Change-Id: I4656d8133da7ee9fcc84ad3f1c7950f924432d1e
