The qt_poll function calls recv to query whether fds marked by select
as readable should be marked POLLIN or POLLHUP in the pollfd structure.
On many platforms such as QNX this requires extra link-time libraries
which were not previously required by QtCore.
While the qt_poll function is intended as a fallback mechanism only for
those platforms which do not implement poll natively, the function was
compiled unconditionally whenever QT_BUILD_INTERNAL was defined, e.g.
in developer builds.
Additionally the function was included on those systems that define poll
in system headers so that configure determines build-time availability,
but do not define _POSIX_POLL > 0 or indicate POSIX:2008 compliance via
either the _POSIX_VERSION or _XOPEN_VERSION macros. On those systems a
sysconf query for _SC_POLL was performed to determine at runtime whether
to call the system poll or qt_poll.
Both of these cases are in fact counterproductive. In the first case the
sole consumer of the function is a single manual unit test. In the
second, to my knowledge no platform requires the runtime fallback.
Despite that, we were forcing an extra dylib in both cases.
Both cases are fixed by 1) moving the implementation into its own file
for the unit test to include and 2) dropping the dynamic fallback if
configure determines availability of poll at compile-time.
This also reverts commit 1377709711, which
added -lsocket for QtCore on QNX.
Change-Id: I2dd10695c5d4cac81b68d2c2558797f3cdabc153
Reviewed-by: James McDonnell <jmcdonnell@qnx.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
That implies we need to differentiate between a variable set but empty
and an empty variable. GCC, Clang and the Intel compiler accept -msse2
on 64-bit builds without warning (they also accept -mno-sse2), but the
Microsoft compiler does not have that option.
Change-Id: I54233388ba10994996ae3e749fd829085e8fd7b7
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
This is needed to be able to use Qt (with dynamic ANGLE) in a plugin
while the host runs a different version of Qt (and ANGLE).
In addition to changing the LIBEGL_NAME and LIBGLESV2_NAME variables
you also need to update the value of the LIBRARY definition in the
.def files for ANGLE:
qtbase/src/3rdparty/angle/src/libGLESv2/libGLESv2[d?].def
qtbase/src/3rdparty/angle/src/libGLESv2/libEGL[d?].def
Task-number: QTBUG-48431
Change-Id: Idd00d039ba3e20cc0ec7496bee36ed1c90383b0d
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@theqtcompany.com>
Visual Studio version specific changes have been added to msvc-
desktop.conf which is not used in WinRT or Windows Phone related builds.
Hence take a similar approach to gcc and introduce msvc-base to be used
by all configurations for common settings.
For WinRT this will only be applied to msvc2015 and later on to not
introduce any regressions or behavior changes for previous versions.
Change-Id: Ib1a4d539d46d788470c00cb5969fee74a803bd67
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Reviewed-by: Oliver Wolff <oliver.wolff@theqtcompany.com>
The platform is no longer supported or actively maintained, and is
in the way for improvements to the Unix event dispatcher and QProcess
implementations.
Change-Id: I3935488ca12e2139ea5f46068d7665a453e20526
Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
While all apps need to have internetClient as a capability, the option
to provide further capabilities via qmake has been removed in the
template.
Instead we add the required items inside the prf and keep the manifest
template as generic as possible.
Task-number: QTBUG-49504
Change-Id: If26b9da277a5269a57b34e74c146b40b1b64d091
Reviewed-by: Oliver Wolff <oliver.wolff@theqtcompany.com>
Reviewed-by: Andrew Knight <andrew.knight@intopalo.com>
... and make use of it in qt.prf.
[ChangeLog][qmake][Unix] Added support for relative paths in
QMAKE_RPATHDIR.
Note that this technically breaks backwards compatibility, as relative
paths were previously silently resolved against $$_PRO_FILE_PWD_. This
was not documented and seems rather useless, so i'm not worried.
Change-Id: I855042a8962ab34ad4617899a5b9825af0087f8a
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
Reviewed-by: Jake Petroules <jake.petroules@theqtcompany.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
If that section is there but empty, the manifest cannot be loaded using
the App Manifest Designer in Visual Studio.
Task-number: QTBUG-48648
Change-Id: I529eb2f2a690bececcf5c385b8f96e84ece363d6
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Reviewed-by: Maurice Kalinowski <maurice.kalinowski@theqtcompany.com>
We no longer support any compilers that don't know the actual version
number of the standard.
Change-Id: Ib056b47dde3341ef9a52ffff13ef154791dd0d22
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
Instead of lumping both Objective-C (.m) and Objective-C++ (.mm) sources
into the same pile, passing them on to the same compiler as for C++ (CXX),
with the C++ flags (CXXFLAGS), we follow Apple's lead and treat them as
variants of the C and C++ languages separately, so that Objective-C
sources are built with CC and with CFLAGS, and Objective-C++ sources
with CXX, and CXXFLAGS.
This lets us remove a lot of duplicated flags and definitions from the
QMAKE_OBJECTIVE_CFLAGS variable, which in 99% of the cases just matched
the C++ equivalent. The remaining Objective-C/C++ flags are added to
CFLAGS/CXXFLAGS, as the compiler will just ignore them when running in
C/C++ mode. This matches Xcode, which also doesn't have a separate build
setting for Objective-C/C++ flags.
The Makefile qmake generator has been rewritten to support Objective-C/C++
fully, by not assuming that we're just iterating over the C and C++
extensions when dealing with compilation rules, precompiled headers, etc.
There's some duplicated logic in this code, as inherent by qmake's already
duplicated code paths, but this can be cleaned up when C++11 support is
mandatory and we can use lambda functions.
Task-number: QTBUG-36575
Change-Id: I4f06576d5f49e939333a2e03d965da54119e5e31
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@theqtcompany.com>
make sure that all specs define QMAKE_{PREFIX,EXTENSION}_{SH,STATIC}LIB,
and adjust the code to make halfways consistent use of these variables,
in particular on windows; Win32MakefileGenerator::getLibTarget() is gone
as a result, as is QMAKE_CYGWIN_SHLIB. still, tons of hardcoded "lib"
references remain in the unix generator, because no-one cares.
Change-Id: I6ccf37cc562f6584221c94fa27b2834412e4e4ca
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
that way we can override the values defined there.
Change-Id: Ib9bce596d9fd43875b26a97c5489ee9d0d46b77c
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
it was experimentally added in 2011. there is no evidence that anyone
actually uses it.
Change-Id: Ie3b131f3783cafe942d180b2623fcc64740d7a73
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
it must come first, as it is most specific.
an alternative fix would be re-organizing the includes, but that
requires a lot more effort to get right.
Change-Id: I1526a3c966f3dc3f3df1efc00ec271d333ed7ebf
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
If no_generated_target_info is not set, VERSION is set, and
there is no .rc file that belongs to the project, qmake creates a
.rc file that contains information about the target's version
and copyright, for example. This resource handling is also
supported by WinRT and we can add this information to the target.
On Windows Phone, winresrc.h (which is needed for resource
handling) is not available though. When trying to add a .rc file
to a project in Visual Studio, it also complains about winres.h
not being available. Instead of hacking around the issue, we
just should not support this behavior on Windows Phone.
Change-Id: Ie962bfa790916fed23294110062e3572a0e317f9
Reviewed-by: Andrew Knight <andrew.knight@intopalo.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
This linker script is only enabled for systems with GCC or GCC-like
compilers, though technically it should work on the BSDs too (will
enable after testing). For regular modules, this declares one ELF
version "Qt_5" and places all QtCore symbols inside, then it declares
unused ELF versions "Qt_5.x" for each older minor release. For modules
declared "internal_module", all symbols are placed in version
Qt_5_PRIVATE_API.
The big advantage of an ELF version is that, when we do Qt 6, both
versions of QtCore could be loaded in memory without conflicts and all
symbols would be resolved to the correct library. No module can talk to
both at the same time, but this avoids mistakes of loading them
indirectly by plugins.
The extra Qt_5.x versions will be used in the next commit.
Change-Id: I049a653beeb5454c9539ffff13e3fe6f050fdf31
Reviewed-by: Lisandro Damián Nicanor Pérez Meyer <perezmeyer@gmail.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
[ChangeLog][General Improvements] Qt's buildsystem now detects whether
the compiler supports C++14 and experimental support for C++1z. If the
compiler supports it, then Qt is automatically compiled using that
support.
\
This does not apply to user applications built using qmake: those are
still built with C++11 support only. To enable support for C++14 in your
application, add to your .pro file: CONFIG += c++14 (similarly for
C++1z).
Change-Id: Ib056b47dde3341ef9a52ffff13ef1f5d01c42596
Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
Change-Id: Iee8cbc07c4434ce9b560ffff13ca466263abcb1b
Reviewed-by: Richard J. Moore <rich@kde.org>
Reviewed-by: Rafael Roquetto <rafael.roquetto@kdab.com>
Reviewed-by: Andrew Knight <andrew.knight@intopalo.com>
The architecture needs to be specified to be properly used inside Visual
Studio and for winrtrunner to parse dependencies.
Change-Id: I218100f33efcba9f78199cbd1e48089269648e61
Reviewed-by: Andrew Knight <andrew.knight@intopalo.com>
So far the dependency keyword has been ignored for the new Windows 10
mkspecs. The difference to older manifest files is that there is already
a <Dependency> section and hence we embed dependencies inside this one,
as the format standard does not allow to have multiple of those.
Change-Id: I1bf25979cc28d5c153215de5bb9cd6f37e9c50aa
Reviewed-by: Andrew Knight <andrew.knight@intopalo.com>
Since libstdc++ builds on OS X and QNX 6.5 are no longer supported,
simply require <initializer_list> and std::move in order to claim C++11
support works.
The minimum OS X versions need to be fixed elsewhere.
Change-Id: Ib056b47dde3341ef9a52ffff13ef1d2ac3923f5c
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Reviewed-by: Jake Petroules <jake.petroules@petroules.com>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@theqtcompany.com>
Reviewed-by: Rafael Roquetto <rafael.roquetto@kdab.com>
Fix the flood of warnings:
src/corelib/global/qflags.h(52): warning C4577: 'noexcept' used with no exception handling mode specified; termination on exception is not guaranteed. Specify /EHsc
now occurring since we don't have exception handling enabled.
Change-Id: I05d12ee6303b4f9fceb48507fadfd7d1a5604ea4
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
These macros are not defined unless a desktop or standalone SDK is
installed.
Change-Id: I4c600ddca5944cc5fde310e4fbe0866a7250d36b
Reviewed-by: Oliver Wolff <oliver.wolff@theqtcompany.com>
Most people's yacc are actually a symlink to bison. On Windows, where
symlinks don't usually exist, we can use bison -y.
This was tested with MSYS Bison.
Change-Id: I913745d48af30f9ef7b846b6438500261dd6022d
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Prefer -std=gnu++11 unless strict_c++11 is defined. You can enable
strict C++11/C++14 mode by using
CONFIG += strict_c++
That is enabled for Qt's own code, so we we don't accidentally use GNU
extensions in portable code.
There's no support for strict C++98 mode (that is, the -ansi option).
[ChangeLog][qmake] By default, GNU extensions are now enabled with
Clang, GCC and ICC even in C++11 and C++14 modes. To disable the GNU
extensions, add to your .pro file: CONFIG += strict_c++.
Change-Id: Ib056b47dde3341ef9a52ffff13ef14de2169bef5
Reviewed-by: Kai Koehne <kai.koehne@theqtcompany.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Clang does not recognize the compiler flag 'no-arc-abi' anymore.
This causes a warning, which will fail the build. Not sure
what the flag does, as I cannot find any documentation for it, even
after grep-ing through the sources (both clang-600.0.57 and
clang-503.0.38)
Change-Id: I39fae3fd108a8edb978f4264935a069cce4c302a
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@theqtcompany.com>
This allows creation of applications for
- x86
- x64
- arm
While the arm build theoretically also allows to launch on
a mobile, it currently asserts on runtime. Either we will
create a new mkspec for Windows 10 Mobile in the future,
or do runtime checks for the environment. That also depends
on whether there will be a separate SDK by Microsoft.
Change-Id: I510bfc88410a5b5a1eb7c37f7f43888d1e5dda0d
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Reviewed-by: Oliver Wolff <oliver.wolff@theqtcompany.com>
Reviewed-by: Andrew Knight <andrew.knight@intopalo.com>
On desktop windows we define _HAS_EXCEPTIONS=0 to also forward this
option. Hence harmonize this with WinRT builds as well.
As a side-effect qtdeclarative now compiles without warnings on WinRT.
Change-Id: I8e343f172160991ffb2ede01303802f321de82b5
Reviewed-by: Kai Koehne <kai.koehne@theqtcompany.com>
Reviewed-by: Oliver Wolff <oliver.wolff@theqtcompany.com>
GCC 5 combined with a recent binutils have a new optimization that
allows them to generate copy relocations even in -fPIE code. Clang has
the same functionality when compiling an executable with -flto. We need
to let the compilers know that they cannot use copy relocations, so they
need to use really position-independent code.
Position independent code throughout is not really required. We just
need the compilers to use position-independent access to symbols coming
from the Qt libraries, but there's currently no other way of doing that.
Task-number: QTBUG-45755
Change-Id: I0d4913955e3745b69672ffff13db5df7377398c5
Reviewed-by: Simon Hausmann <simon.hausmann@theqtcompany.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
this allows LD_LIBRARY_PATH to take precedence over the hard-coded
rpath, which is the only sane thing to do (which is also why i'm not
adding an option to disable it).
this behavior is consistent with non-linux systems.
the windows version has no auto-detection, just like for gold linker
usage.
Task-number: QTBUG-3069
Change-Id: Ief9ba032291c898d75d76ecc740390954382a804
Reviewed-by: Simon Hausmann <simon.hausmann@theqtcompany.com>
The flags are the same across all GCC flavors so put the definition
in the common gcc-base.conf instead of duplicating it in g++-base.conf
and clang.conf
Change-Id: I1ba2c3c314d3a02b559c384aecef74240f69f659
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@theqtcompany.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
The variables used for release with debuginfo was set in g++-base.conf
which is not included by clang builds.
Change-Id: Iec3b23c371c113ff934d2c7f5134ef78b1cf939e
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
This issue had been fixed by SHA: a12a2fdf68
but re-introduced by SHA: c23d1c7695 again.
Task-number: QTBUG-45085
Change-Id: If98ee108335d80035179a83b1b28f384395d8373
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@theqtcompany.com>
Neon detection in configure does not work unless correct
flags are passed to compiler.
Task-number: QTBUG-44690
Change-Id: If119cc9ed80275aaa8796c1be8853559a7670d6a
Reviewed-by: Sean Harmer <sean.harmer@kdab.com>
Reviewed-by: Rafael Roquetto <rafael.roquetto@kdab.com>
it makes no sense to let every spec do that separately, as it's fixed
by the generator+shell.
putting it into a file which is loaded regardless of the spec also
allows us to remove the hardcoded fallbacks from qmake.
if somebody overrode the values in their spec for some weird reasons,
they'll need to override spec_post.prf.
shell-{unix,win32}.conf are now dummies and print warnings.
Task-number: QTBUG-37269
Change-Id: I66c24fb4072ce4d63fdbfc57618daa2a48fa1d80
Reviewed-by: Jochen Seemann <seemann.jochen@gmail.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
Moc doesn't have the built in defines that clang has, so we need to
hard-code some of these so that moc resolves the Q_OS_IOS define
in the end, based on qsystemdetection.h and TargetConditionals.h
Change-Id: Id9a7f870b940f99f27c55a2a887d0ce93217b821
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Due to common subexpression elimination instruction set extensions may
leak from the objects where they were enabled when doing link-time
optimizations.
To avoid that this patch disables LTCG/LTO on files built with extra
instruction set extensions.
Change-Id: Ie34ad900be7fb04a0dc4d3562187ee170c183333
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
We've been setting the -Zm argument since the dawn of times (even before
the first git commit). Anyhow, MSDN from VS2008 onwards indicates
that this is not needed:
"In earlier versions of Visual C++, the compiler used several discrete
heaps, and each had a finite limit. Currently, the compiler dynamically
grows the heaps as necessary up to a total heap size limit, and requires a
fixed-size buffer only to construct precompiled headers. Consequently, the
/Zm compiler option is rarely necessary."
[ChangeLog][Compiler Specific Changes] Visual Studio: -Zm200 (an option to
specify the precompiled header memory allocation limit) is not added anymore
by qmake to the compiler calls. If you encounter an C1076 compiler error you
might need to re-add it in your .pro file.
Change-Id: Ia4bec7eba09d893a7d81886a1814602b9ce7563c
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@theqtcompany.com>
QtWebEngine and QtWebKit uses the Qt config to detect if C++11
is enabled. Since it is always enabled on MSVC, we can safely
set the flag indicating it is a C++11 build when using a newer
MSVC version.
Change-Id: I2efb8d1a9b1cf1496481569403c00358d0cae365
Reviewed-by: Michael Brüning <michael.bruning@theqtcompany.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
