Intel CC 12.1 supports AVX2 but only with -march=core-avx2. The -mavx2
option produces a warning.
GCC 4.6 does not recognise any option.
GCC 4.7 recognises both -mavx2 and -march=core-avx2 so let's use the
latter for now. We may need to change to -mavx2 when there's an AMD
processor that supports AVX2 too.
Change-Id: I529240e6e6c2c0e3942d357e0320212d954fe4de
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
This also removes the check for SSE, but the check for SSE2 and
further technologies is kept. If SSE2 is present, then SSE is too. We
don't have any code that uses the original SSE instructions only.
Remove the CMOV detection, since we don't use that anywhere and we're
not likely to ever use them..
Change-Id: I3faf2c555ad1c007c52a54644138902f716c1fe1
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
The regular expression should look for underscores in addition to
alphanumeric characters.
Change-Id: Idc3dbd67291ec1420f818d74fba8413b1e7cbcf1
Reviewed-by: Girish Ramakrishnan <girish.1.ramakrishnan@nokia.com>
Reviewed-by: Bradley T. Hughes <bradley.hughes@nokia.com>
Any message/error in mkspecs or qmake feature files ends up confusing
the current arch detection logic. Instead, search for
"Project MESSAGE: .* Architecture: <arch>".
Change-Id: I308932a5b75f3a1fcbc4fe30c74faf2e83b2d752
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
config.tests/unix/freetype.pri has a !cross_compile flag, so we must
find freetype using the proper detection methods. The detection was
inside an X11 section of configure, so move that out.
And use the results of that detection, now that QMAKE_CFLAGS_X11 isn't
used (since we're not building X11 in QtPlatformSupport).
Change-Id: Ic8f5cfb7263849bfb12967756def2b5aaa244872
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
The bsymbolic_functions test was missing $SYSROOT_FLAG, so the linking
was always failing and the test falsely negative.
Also make the error reporting better: if the flag was requested, error
out if the check fails and report more information in -v mode.
Change-Id: Ie2615f8083e7e58d63d9ee9c23be937dc864b30d
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
With the move to the QPA architecture EGL is now only required by
individual platform plugins and the configure script has been adjusted to
reflect this.
Change-Id: Ieadacef0b970f29752d9e3e36a007e5cbb005b0d
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
Reviewed-by: Girish Ramakrishnan <girish.1.ramakrishnan@nokia.com>
The XCB plugin requries libxcb >= 1.5. Configure and
config.tests/qpa/xcb now check for this.
Change-Id: I96c688b79bf5b49fd3ecc4ddc12ebdc2d3788790
Reviewed-by: Samuel Rødal <samuel.rodal@nokia.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
Without this, QMAKE_RPATHDIR is empty and qt_module.prf's logic to turn
on absolute_library_soname fails, causing some modules to build without
absolute paths (eg. qtjsbackend's QtV8 framework).
Change-Id: If03136ca60a5d8a96a589e2d1034e5884fd6a1ac
Reviewed-by: Michael Brasser <michael.brasser@nokia.com>
Makes no sense to disable iconv based on QPA. This change will
make iconv as the "system" codec i.e the codec used for 8-bit
locale dependent conversions.
Change-Id: I4469e9c226b2411ac1338f61dabb84ec9c2ec603
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Lars Knoll <lars.knoll@nokia.com>
This patch ensures that additional runpaths passed to configure via
the -R switch are added to the QMAKE_RFLAGSDIR variable.
Previously, although runpaths provided in this way were appended to the
linker options when building Qt itself, they were not appended to
the QMAKE_RFLAGSDIR value written to mkspecs/qconfig.pri. This meant
that the DT_RPATH attribute was set incorrectly in binaries built from
projects other than Qt itself.
-----------------------------------------------------------------------
Configure flags Expected value Value before this fix
-----------------------------------------------------------------------
<none> DEFAULT_RPATH DEFAULT_RPATH
-no-rpath <empty> <empty>
-R X DEFAULT_RPATH:X DEFAULT_RPATH
-no-rpath -R X X <empty>
-prefix Y Y/lib Y/lib
-prefix Y -no-rpath <empty> <empty>
-prefix Y -R X Y/lib:X Y/lib
-prefix Y -no-rpath -R X X <empty>
-----------------------------------------------------------------------
DEFAULT_RPATH = /usr/local/Qt-${QT_VERSION}/lib
Change-Id: Iaf1809b528ebd249694cf41e004173e881ca48ad
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
There should be a clear QWidget free path for people with no interest in
legacy QWidget functionality. Adding this option to configure makes this
path readily accessible and hence testable.
Change-Id: If87c1063fcf4c46f5280836126c11999feaa9f8a
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
Do not try to detect the host or target architectures using uname or
similar, and do not override with the -arch or -host-arch configure
arguments. The configures will still accept the -arch and -host-arch
arguments, but it ignores them and instead outputs a warning stating
that these arguments are obsolete and should not be used.
Set QT_ARCH and QT_HOST_ARCH qconfig.pri variables based on the compiler
target. This is done by running qmake (twice when cross-compiling) on
config.tests/arch/arch.pro, which preprocesses a file that contains all
knowns processors.
On Windows, configure.exe has never run any config.tests before, and
does not currently have a function to run a program and capture its
output. Use _popen() to accomplish this (as qmake does for its system()
function). This needs to be done after qmake is built, as does the
mkspecs/qconfig.pri generation. As a side effect, the configure steps
have been slightly re-ordered, but the overall result is the same. The
displayConfig() call is moved to just before generating Makefiles, so
that it can show the detected architecture(s).
Change-Id: I77666c77a93b48848f87648d08e79a42f721683f
Reviewed-by: Morten Johan Sørvig <morten.sorvig@nokia.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
When cross-compiling, check for PKG_CONFIG_LIBDIR instead of
PKG_CONFIG_PATH. pkg-config searches for pc files in PKG_CONFIG_PATH
*and* the compiled in defaults (/usr/lib/pkgconfig). This means that
pc files from the host get found when cross-compiling.
Setting PKG_CONFIG_LIBDIR makes pkg-config search only in the path
set in PKG_CONFIG_LIBDIR.
Documented in the url below:
http://www.freedesktop.org/wiki/Software/pkg-config/CrossCompileProposal
Change-Id: I22dbf29c5691572b7cb8a5fce712ae7ba811670e
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
Config checks are done in the module.
We pick up the pkg-config stuff also in the module. There shouldn't be a
need to do this in configure anyway
Change-Id: I9ef73760511c6b684c6cd5dd13e7e581c588e7aa
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
the feature is rather obscure and unlikely to be used by anyone.
Change-Id: I2dfb4ca4d5d1f210d385c013f46bc6389fd6ea2d
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
Logic was clearly always off kilter, and this was only defined for GUI
builds
Change-Id: Ie85c156510e7c450a5192408b4c365ff07ce2029
Reviewed-by: Donald Carr <donald.carr@nokia.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
make is perfectly capable of doing shadow builds
Change-Id: I7e1c27cddc385b7a17ae5645b9cd26fa56d2f029
Reviewed-by: Marius Storm-Olsen <marius.storm-olsen@nokia.com>
.qmake.cache is not necessarily accessible to other modules which depend on
information about whether we are cross compiling or not. We might as well
advertise this fact globally via the CONFIG variable in qconfig.pri.
Change-Id: I6dee3e6604e5ca1c775c5f9f834fe29b4e27adb8
Reviewed-by: Donald Carr <donald.carr@nokia.com>
Reviewed-by: Girish Ramakrishnan <girish.1.ramakrishnan@nokia.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
Reviewed-by: Johannes Zellner <johannes.zellner@nokia.com>
this is oxymoronic: if a .qmake.cache is present, telling qmake the
project root is utterly pointless.
the windows variant never had this.
Change-Id: Iefc6e242ad7458dc699b955a3657f31f1ecf4c7b
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
the tool locations are now determined with qtPrepareTool(), which takes
non-installed qt builds into account already.
Change-Id: I17b2c5f4b181417f2a612be2f540768e7dc0ae4e
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
the problem this (probably) tried to solve has been solved via ordered
builds a *long* time ago.
Change-Id: I84c58076c864735eea4210ec60aa060fe3e5d97e
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
We need qdoc in qtbase to be able to properly
modularize our documentation and build it
when building the different Qt modules.
qdoc does contain a copy of the qml parser from
qmldevtools, but this is the lesser evil compared
to how we are currently forced to genereate our
docs (and the fact that no developer can run
qdoc and check the docs for their module).
Change-Id: I9f748459382a11cf5d5153d1ee611d7a5d3f4ac1
Reviewed-by: Casper van Donderen <casper.vandonderen@nokia.com>
Reviewed-by: Martin Smith <martin.smith@nokia.com>
Do not write Q_BYTE_ORDER to qconfig.h in the configures. Instead,
we #define Q_BYTE_ORDER in qprocessordetection.h, since many CPUs only
support a single endian format. For bi-endian processors, we set
Q_BYTE_ORDER depending on how the preprocessor sets __BYTE_ORDER__,
__BIG_ENDIAN__, or __LITTLE_ENDIAN__ (instead of using a compile test
to do so).
For operating systems that only support a single byte order, we can
check for Q_OS_* in addition to the preprocessor macros above. This is
possible because qprocessordetection.h is included by qglobal.h after
Q_OS_* and Q_CC_* detection has been done. Do this for Windows CE,
which is always little- endian according to MSDN.
Change-Id: I019a95e05252ef69895c4b38fbfa6ebfb6a943cd
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
instead of being a variable added to the makespec (via qconfig.pri),
QT_SYSROOT is now a property.
the QT_INSTALL_... properties are now automatically prefixed with the
sysroot; the raw values are available as QT_RAW_INSTALL_... - this is
expected to cause the least migration effort for existing projects.
-hostprefix and the new -hostbindir & -hostdatadir now feed the new
QT_HOST_... properties.
adapted the qmake feature files and the qtbase build system accordingly.
Change-Id: Iaa9b65bc10d9fe9c4988d620c70a8ce72177f8d4
Reviewed-by: Marius Storm-Olsen <marius.storm-olsen@nokia.com>
Remove the -armfpa option the config.tests/unix/doubleformat*
detection. The places where we used QT_ARMFPA and Q_DOUBLE_FORMAT
has been removed as well.
Rationale: ARM FPA with GCC does not work with EABI. Qt currently
does not support compiling without EABI, making ARM FPA an
impossibility. It is unknown whether other compilers provide ARM FPA
support with EABI. Support for ARM FPA can be re-added in the future
should the need arise, but since ARM VFP is available for ARMv5 and up,
we should encourage implementors to instead use soft-floats or VFP.
Change-Id: I3671aba575118ae3e3e6d769759301c8f2f496f5
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
switch blocks are noisy. this is nicer.
reshuffled the LibraryLocation enum to make table lookups possible and
future-safe.
using pointer-free tables to avoid adding data relocations.
Change-Id: I70ec2c2142ce02a15e67284e4b285d754d930da3
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
evidently, The Author had no clue that the compiler will do that
automatically.
as it happens, the windows configure already did it right.
Change-Id: I7ebc018c254b316205348874ffa527526329b630
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Prior to this change, explicitly passing -qpa to configure breaks compilation on Mac. This is due to a false dichotomy between MAC/QPA
Change-Id: I52cacf96ae8d8d203787f9bbade417f2c55ab3f1
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
Reviewed-by: Morten Johan Sørvig <morten.sorvig@nokia.com>
This should make it less confusing for people building Qt 5 on Linux.
Change-Id: I3aa7151f790587d5944c837d701b1b1b580b4bc3
Reviewed-by: Alan Alpert <alan.alpert@nokia.com>
configure was unconditionally attempting to create two symlinks to
qconfig.h: include/Qt/qconfig.h, and include/QtCore/qconfig.h.
include/Qt doesn't exist any more, so this would always cause a
"No such file or directory" warning. Remove that one.
include/QtCore/qconfig.h is usually created by syncqt now, so this would
cause a "File exists" warning. Make that one conditional.
Change-Id: I8c6244dcbcf9765444f0d5c40c91a0ca192ecbcb
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
Direct use of pkg-config variables disregards the sysroot offset pkg-config
factors into consideration with the dedicated variables:
--cflags-only-I
--libs-only-L
these parameters exist exactly for this reason.
Change-Id: Ieecf31ebe0640f64b272b84fba22701aacf8f966
Reviewed-by: Johannes Zellner <johannes.zellner@nokia.com>
Reviewed-by: Donald Carr <donald.carr@nokia.com>
Reviewed-by: Girish Ramakrishnan <girish.1.ramakrishnan@nokia.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
make the "evaluator" able to process simple variable expansions.
cache the processed spec, so it is not re-read for every variable.
Change-Id: I20e69ec7b65faa7d571e68dbfea6c21c79a62641
Reviewed-by: Marius Storm-Olsen <marius.storm-olsen@nokia.com>
and run the configure checks with the values
Change-Id: Ie8e0072c686c6a7dce1d02e25a9c1abce4679d34
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
We no longer support universal ppc/x86 builds.
Change-Id: I8c4a1d087d02da1ad80d91a7a04147b37e81d74f
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
The logic here was wrong: test if the
target linker supports -rpath-link, and then set
it for both host and target via mkspecs/qmodule.pri.
Change-Id: Ie4da7ed2e06e784f9edb65a27290913ab838a8c2
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
