The check was broken on non-bash and producing errors like this:
/home/louai/work/qt5/qtbase/configure: 4528: [: Illegal number:
Change-Id: I5e78ad002cd7cfb401f2646510e0923f77c55f98
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Since the Qt headers require them now, we need to ensure that happens
properly.
Change-Id: Ib306f8f647014b399b87ffff13f14196c2c75bef
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
KMS is no longer a platform plugin so the relevant leftover bits are
now removed.
As the introduction of the EGLDevice-based backend for eglfs shows,
using DRM/KMS is not tied to GBM, separate buffer management
approaches, like EGLStreams, work fine as well. Therefore separate KMS
from GBM and remove the EGL and GLES dependency in the tests - this
way there is nothing preventing us from using GBM without GL for
example.
Change-Id: Id7ebe172b44b315f9a637892237d2bb62d99aed2
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Reviewed-by: Louai Al-Khanji <louai.al-khanji@theqtcompany.com>
For now we pick one crtc and find the corresponding layer. If this is
not desired, set QT_QPA_EGLFS_LAYER_INDEX to override the layer to be
used. Enable qt.qpa.eglfs.kms to get logs about the available layers.
Change-Id: I762783f960739e32966c8cde17d8f55fbe40091f
Done-with: Louai Al-Khanji <louai.al-khanji@theqtcompany.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Reviewed-by: Louai Al-Khanji <louai.al-khanji@theqtcompany.com>
-xvideo was not used even by Qt 4 for a long time.
-xinerama was used by the xlib plugin which was dropped
by e6a7a6a381.
Change-Id: Iea97f643570d98f84ad1ce6f16e911dc92d617b0
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Reviewed-by: Laszlo Agocs <laszlo.agocs@theqtcompany.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>
It's obsolete since e6a7a6a381
(Remove xlib plugin) and a2337f79ff
(Remove Windows and X11 from src/widgets/platforms).
The actual option is -xinput2.
Change-Id: I28bf03963a8edc5c69330605ba072fbfaefb05e3
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
[ChangeLog][QtDBus] The QtDBus library now links directly to the
libdbus-1 system library if it was detected at configure time. To force
linking to the library, pass option -dbus-linked to configure; to force
dynamically loading at runtime, use -dbus-runtime.
Task-number: QTBUG-14131
Change-Id: Ie33d1f22f85b465ab0ce166b8f17b8491eae1c21
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
the purpose is to make build log parsers able to ignore build failures
in verbose configure output.
Change-Id: I01af2e019fd1b055fdfcf6749faeebacb7a39c3f
Reviewed-by: Frederik Gladhorn <frederik.gladhorn@theqtcompany.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
In addition to the proprietary Mali Linux driver bundle from ARM, there
are a couple of semi open source alternative bundles out in the wild,
which are mostly derivatives from the sunxi-mali bundle.
The non-ARM bundles lacks the proprietary header file fbdev_window.h
which defines the fbdev_window struct. Instead, it has an equivalent
mali_native_window struct in the EGL/eglplatform.h (which in turn is
included by EGL/egl.h).
This change adds an alternative configure test which detects the non-ARM
bundles are used. It also removes the dependency on fbdev_window.h by
defining the structure ourselves, which actually makes the plugin
potentially compilable with *any* EGL SDK.
Change-Id: I78ab4b618e8e9c774c889fe9896105cf2cf4228e
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Reviewed-by: Laszlo Agocs <laszlo.agocs@theqtcompany.com>
The C++ standard says it must, but some badly-configured toolchains seem
to be lacking support.
In particular, for some 32-bit platforms without native support for
them, GCC implements 64-bit atomics via out-of-line functions in
libatomic. If that library is missing... well, then std::atomic 64-bit
doesn't work and we mustn't try to use it.
This was found when trying to compile Qt 5.6 for MIPS 32-bit:
Linking library libQt5Core.so.5.6.0
.obj/qsimd.o: In function `std::__atomic_base<unsigned long long>::load(std::memory_order) const':
/opt/poky/1.7/sysroots/mips32r2-poky-linux/usr/include/c++/4.9.1/bits/atomic_base.h:500: undefined reference to `__atomic_load_8'
.obj/qsimd.o: In function `std::__atomic_base<unsigned long long>::store(unsigned long long, std::memory_order)':
/opt/poky/1.7/sysroots/mips32r2-poky-linux/usr/include/c++/4.9.1/bits/atomic_base.h:478: undefined reference to `__atomic_store_8'
Yocto bug report: https://bugzilla.yoctoproject.org/show_bug.cgi?id=8274
Change-Id: I42e7ef1a481840699a8dffff140224d6614e5c36
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
ppc/ppc64 and 32-bit x86 have been dead for a while.
consequently, the legacy macx-g++-64 spec was most probably not used.
which in turn meant that NATIVE_64_ARCH was never set (in particular on
windows hosts ...), which means that the android ndk host auto-detection
was effectively broken.
the arch code in mac/default_post.prf was also never triggered, so nuke
it as well.
Change-Id: Ic0775e40b273a22e0a15808cac328e0df33c2155
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.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>
As planned for 5.6, QtMultimedia now uses GStreamer 1.0 over
0.10 when available.
This means the binary packages will be based on GStreamer 1.0.
Task-number: QTBUG-47920
Change-Id: I9a18569ff96902116f0f6a759c185a5896f520d5
Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
This will allow us to drop gtk2 support from qtbase in future,
while still providing the gtk2 style for those who want to use it.
Also with moving to qtstyleplugins, the code can be simplified
because we can directly link to libraries we need, instead of using
QLibrary.
[ChangeLog][QtWidgets] Remove QGtkStyle, it is now provided in
qtstyleplugins repository.
Change-Id: I6221b1a513d7fda32e080f3ca159b0b2f8a8f246
Reviewed-by: Timo Jyrinki <timo.jyrinki@canonical.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Reviewed-by: Jens Bache-Wiig <jensbw@gmail.com>
Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
Reviewed-by: J-P Nurmi <jpnurmi@theqtcompany.com>
Reviewed-by: Lisandro Damián Nicanor Pérez Meyer <perezmeyer@gmail.com>
SecureTransport is now the default SSL backend on OS X.
Users can still choose the OpenSSL backend by passing the -openssl,
-openssl-linked or -no-securetransport option to configure script.
[ChangeLog][Important Behavior Change] Make SecureTransport the default SSL backend on OS X
Change-Id: I7a4edfdb72e63975d6b31435969702f8e86a10f2
Reviewed-by: Richard J. Moore <rich@kde.org>
Reviewed-by: Morten Johan Sørvig <morten.sorvig@theqtcompany.com>
[ChangeLog][QtCore][Logging] Systems with syslog may now pass -syslog to
configure to send logging output to syslog.
Change-Id: I80d58ee6e70d8deb2409fc666e7e7f2d7f52b8e1
Reviewed-by: Kai Koehne <kai.koehne@theqtcompany.com>
Also solves a warning printed:
configure: 4200: shift: can't shift that many
Change-Id: Ib306f8f647014b399b87ffff13f295e2cdb7f8d7
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@theqtcompany.com>
The pipe2/dup3/accept4 functions and SOCK_CLOEXEC are quite old nowadays
on Linux. They were introduced on Linux 2.6.28 and glibc 2.10, all from
2008. They were also picked up by uClibc in 2011 and FreeBSD as of
version 10.0. So we no longer need the runtime detection of whether the
feature is available.
Instead, if the libc has support for it, use it unconditionally and fail
at runtime if the syscall isn't implemented.
Change-Id: Ib056b47dde3341ef9a52ffff13efcc39ef8dff7d
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
There's really no difference between them, other than -force-pkg-config
skipping the check if the tool is even available and printing a warning.
Change-Id: I04cb83c6649ef73866a84032ea46093c4a00ce00
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Otherwise the information is missing from configure's output summary:
EGLFS ................ no
EGLFS i.MX6....... .
EGLFS KMS .......... no
EGLFS Mali .........
EGLFS Raspberry Pi .
EGLFS X11 .......... no
Change-Id: Iee8cbc07c4434ce9b560ffff13cb331778c70261
Reviewed-by: Laszlo Agocs <laszlo.agocs@theqtcompany.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
The option is named securetransport, not secure-transport.
Change-Id: I5efdde6d751cbc7e9717c6bfe0add93c5dbd2ec9
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
This way we can exclude the connection plugins from being compiled
if it's off.
Change-Id: Ic5ea1d35ea9f5929420268a1aefebf0464d8520b
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
We build our 32 bit Linux packages nowadays on Red Hat 64 bit with
-platform linux-g++-32. Honor this when selecting the right licheck
binary to use.
Change-Id: I08527295bc461c8cdd07e81a10c93a8f010b787d
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Switch to using the pointer events from XI2 when touch is available (i.e.
version is >= 2.2). This allows us to select and grab the button and motion
events together with the touch ones. This prevents the issue of not getting
touch events when grabbing via the plain xcb functions.
To prevent touch sequences from being replayed after ungrabbing (for example after
dismissing a popup that caused a grab), we try to accept touches via XIAllowTouchEvents.
Unfortunately this leads to a deadlock and therefore we can only do it when we know
we have a new enough libXi. This is a configure time check which is not ideal since
the system on which apps run can have a newer libXi than the machine that did the Qt
build, but seems like the best we can do.
The environment variable QT_XCB_NO_XI2_MOUSE can be set to 1 in order to prevent
processing mouse events through XInput. This restores the old behavior with broken
grabbing.
[ChangeLog][QtGui] Pointer event delivery on X11 is now done via XInput 2.2+ when available.
Done-with: Michal Klocek <michal.klocek@theqtcompany.com>
Done-with: Alexander Volkov <a.volkov@rusbitech.ru>
Task-number: QTBUG-43525
Task-number: QTBUG-45054
Task-number: QTBUG-30417
Change-Id: I7cb2002b31bef4cd527aa427549dcf2d5467968e
Reviewed-by: Laszlo Agocs <laszlo.agocs@theqtcompany.com>
Reviewed-by: Shawn Rutledge <shawn.rutledge@digia.com>
Check for a valid license not only in configure, but also in qmake.
To limit the runtime overhead we cache the day of the last run in
a .stash file. This allows us to run licheck only for the top-level
qmake call, and only once per day.
This requires an updated licheck executable that supports the new
check mode.
[ChangeLog][Tools][qmake] For commercial builds, qmake now checks for
a valid Qt license. This requires setting up a Qt Account (or
.qt-license file) on the development machine.
Change-Id: I2c2a05a4602cc661560568b76ddf520cb8134769
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
In the unix commercial packages, licheck so far has been a shell
script that redirected to the 'right' licheck. To simplify things
we now resolve the right executable path in configure itself.
Change-Id: I1183d000a11bf42729f3e0405a0bc1d4b618933c
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Starting with Qt 5.5 qtconnectivity on iOS is supported
Change-Id: I30430ce351b7e2fc8031c5719bed5354ed234cc7
Task-number: QTBUG-45988
Reviewed-by: Timur Pocheptsov <Timur.Pocheptsov@digia.com>
Defaulting to absolute_library_soname on configure -rpath is no longer
necessary as now we support @rpath install name ids on OS X and iOS.
This also sets QMAKE_SONAME_PREFIX to @rpath for Qt modules when built
with rpath configuration.
This makes Qt libraries relocatable on OS X. Qt SDK is not yet
relocatable though, because plugin locations (including cocoa plugin)
are still resolved using absolute path (see QTBUG-14150). Also, there
are several absolute paths hardcoded in qmake mkspecs pri files.
Task-number: QTBUG-31814
Change-Id: I36b9384cd69ac609608acbe2b3d5e0512317e0d6
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@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>
subsequent tests should depend on the detected linker, obviously.
Change-Id: I09aa9f1f2ef789f0ae0829f9122211fc4e1ad518
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
this function does not just compile, but it also links, so the output
file should have no object file extension.
Change-Id: I65dd9bd334478545ceeabe9d1aacb44d9583cdd7
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
Test each include file directly, instead of doing a large #include. This
verifies that each header is compilable on its own. One big advantage of
doing it via a special compiler in qmake is that we skip pre-compiled
headers, which has hidden build errors in the past.
This solution is implemented by making syncqt produce a second list of
headers. This list is the same as the list of headers in the source
code to be installed, minus the headers that declare themselves to be
unclean, via the pragma:
#pragma qt_sync_skip_header_check
This mechanism is applied only for public libraries (skipping
QtPlatformSupport, an internal_module).
This test is enabled only for -developer-builds of Qt because it
increases the compilation time.
On QtTest: the library only links to QtCore, but it has two headers that
provide inline-only functionality by including QtGui and QtWidgets
headers (namely, qtest_gui.h and qtest_widget.h). If those two modules
aren't getting compiled due to -no-gui or -no-widgets to configure, we
need to remove the respective headers from the list of headers to be
checked. If they are being built, then we need to make QtTest's build
wait for the headers to be generated and that happens when qmake is
first run inside the src/gui and src/widgets directories.
Change-Id: I57d64bd697a92367c8464c073a42e4d142a9a15f
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
