This commit fixes an issue introduced in commit
ac16793eaa. This commit creates a link
$(@D)/bin/python pointing to the host Python 2, and adds $(@D)/bin/ to
the PATH. However, the QT5WEBKIT_INSTALL_TARGET_CMDS variable copies the
contents of $(@D)/bin/ to the target filesystem, in order to install
binaries produced by the qt5webkit build. By doing this, we overwrite
the 'python' symbolic link on the target.
In order to fix this, we simply create the 'python' symbolic link used
to trick qt5webkit to use python2 on the host in the $(@D)/host-bin/
sub-directory.
Signed-off-by: Johan Derycke <johan.derycke@barco.com>
Tested-by: Yegor Yefremov <yegorslists@googlemail.com>
[Thomas: rework commit log.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
As explained in
https://wiki.qt.io/New_Features_in_Qt_5.6#Technology_Preview_Modules,
not only qt5quickcontrols2 is a technology preview component in Qt 5.6,
but also qt53d, qt5serialbus.
Signed-off-by: Matt Kraai <kraai@ftbfs.org>
[Thomas: improve commit log with a reference.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Some Qt5 sub-projects as well as 3rd-party apps written on Qt
are failing to compile with gcc 6.x like that:
---------------------------->8-------------------------
In file included from XXX/output/host/usr/arc-buildroot-linux-uclibc/include/c++/6.2.1/bits/stl_algo.h:59:0,
from XXX/output/host/usr/arc-buildroot-linux-uclibc/include/c++/6.2.1/algorithm:62,
from XXX/output/host/usr/arc-buildroot-linux-uclibc/sysroot/usr/include/qt5/QtCore/qglobal.h:88,
from XXX/output/host/usr/arc-buildroot-linux-uclibc/sysroot/usr/include/qt5/QtCore/qpair.h:37,
from qmediametadata.h:37,
from qmediametadata.cpp:28:
XXX/output/host/usr/arc-buildroot-linux-uclibc/include/c++/6.2.1/cstdlib:75:25: fatal error: stdlib.h: No such file or directory
#include_next <stdlib.h>
^
compilation terminated.
---------------------------->8-------------------------
That happens because qmake trying to play smart passes some
include paths in Makefile with "-isystem" prefix.
Which in some cases lead to build failure well described in [1].
A little bit more details below on what really happens:
1. In "configure" script Qt determines default include paths of the
toolchain and stores them in DEFAULT_INCDIRS variable, see [2].
2. On qmake execution when it creates Makefile out of .pro-file
it parses headers in INCLUDEPATH variable and if a path matches
one in DEFAULT_INCDIRS then in CXXFLAGS that path is written
with $QMAKE_CFLAGS_ISYSTEM prefix, otherwise non-matching include
path ends up in CXXFLAGS with normal "-I" prefix.
3. By default for gcc "QMAKE_CFLAGS_ISYSTEM = -isystem", see [3].
4. gcc fails to find stdlib.h, again refer to Jörg's explanation in [1].
What we do here we force set QMAKE_CFLAGS_ISYSTEM to "" and so qmake
won't use "-isystem" any longer instead expected "-I" will be used for
all headers, see [4].
That fixes building of Qt5Webkit on ARM with gcc 6.x and a number of
autobuilder failures for ARC (the an arch that uses gcc 6 by default) like:
http://autobuild.buildroot.net/results/56a/56a6700774af692e7f5a99b452b15e4e8592310fhttp://autobuild.buildroot.net/results/697/697412b29bf031bf8f246cc3af97ebcbf6bf6d1b
[1] https://git.buildroot.net/buildroot/commit/?id=e79272fa7ff3d66c18de3514b912cd9d68d121a4
[2] http://code.qt.io/cgit/qt/qtbase.git/tree/configure?h=5.6.1#n3660
[3] http://code.qt.io/cgit/qt/qtbase.git/tree/mkspecs/common/gcc-base.conf?h=5.6.1#n47
[4] http://code.qt.io/cgit/qt/qtbase.git/tree/qmake/generators/unix/unixmake2.cpp?&h=5.6.1#n193
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Peter Seiderer <ps.report@gmx.net>
Cc: Julien Corjon <corjon.j@ecagroup.com>
Cc: "Yann E. MORIN" <yann.morin.1998@free.fr>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Fix qt5enginio version, is 1.6.1 for qt5.6.1-1 (hash
is already updated by previous qt5 bump version patch).
Signed-off-by: Peter Seiderer <ps.report@gmx.net>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Qt5 can optionally enable udev support, especially to enumerate input
devices dynamically. Without udev, devices are not properly enumerated,
and any device that is not present at launch time is never seen (there
is no support for hotplug, that is).
Currently, Qt5base has no explicit dependency on udev, so it will all
depend on the build order. Sometimes, a package that requires udev will
be built before qt5base and Qt5 will have support for udev, sometime no
such package is built before qt5base and Qt5 will not have support for
udev.
Add an explicit dependency on udev, but only if it is enabled.
Note: this only really requires libudev, but we do not yet have a
separate libudev; we still only have a udev provider (be it eudev or
systemd).
Signed-off-by: "Yann E. MORIN" <yann.morin@orange.com>
Cc: Cedric Chedaleux <cedric.chedaleux@orange.com>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
[Thomas: drop comment, as suggested by Arnout.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This commit adds an upstream qtbase commit that fixes the detection of
ALSA versions >= 1.1.x, as we have in Buildroot.
Signed-off-by: Jiri Novotny <jiri.novotny@logicelements.cz>
[Thomas: change to use the upstream commit directly, using <pkg>_PATCH.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Julien Corjon <corjon.j@ecagroup.com>
[Thomas:
- remove useless 'depends on' on toolchain features, since we now
depend on bluez_utils/neard
- remove the QT5CONNECTIVITY_INSTALL_TARGET_QMLS variable, and directly
use QT5CONNECTIVITY_INSTALL_TARGET_BLUETOOTH_QMLS and
QT5CONNECTIVITY_INSTALL_TARGET_NFC_QMLS in
QT5CONNECTIVITY_INSTALL_TARGET_CMDS.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Qt5Multimedia needs Qt5OpenGL module in case OpenGL support is
enabled.
Fixes bug reported by Marco Trapanese ([1]).
[1] http://lists.busybox.net/pipermail/buildroot/2016-May/161288.html
Signed-off-by: Peter Seiderer <ps.report@gmx.net>
Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Although this package has been removed from the official release
packages since Qt5.6.0, it is still available for users to build
it from source. This is useful for platforms without GPU since its
successor (QtWebEngine) requires OpenGL support.
The package now matches the community-based meta-qt5 Yocto layer,
using the exact same revision of the qtwebkit source from github:
https://github.com/meta-qt5/meta-qt5/commit/e434995a
Here is the project source tree:
https://github.com/qtproject/qtwebkit
All the patches have been pulled from Yocto as well.
Since we are now using the source from the git repository, we need
to create an empty .git/ folder to force the headers re-generation.
https://github.com/meta-qt5/meta-qt5/blob/jethro/recipes-qt/qt5/qt5.inc#L33
Note that GPLv3 license option has been added with this release.
Reviewed-by: Julien Corjon <corjon.j@ecagroup.com>
Signed-off-by: Gary Bisson <gary.bisson@boundarydevices.com>
[Thomas: fix license to be LGPLv2.1+, not LGPLv2+.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
All Qt5 packages gained the GPLv3 license option and all the documentation
is now under GFDLv1.3 license (except qt5websocket and qt53d)
Signed-off-by: Julien Corjon <corjon.j@ecagroup.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
- add hint to help text
- add assimp dependency
- always install the gltf (and any future) sceneparser to target.
Signed-off-by: Peter Seiderer <ps.report@gmx.net>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Tested-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
[Thomas: update commit message as suggested by Arnout.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The BR2_ARCH_HAS_ATOMICS was added because on ARC, atomic instructions
may not be provided by the architecture and therefore the compiler
does not provide the __sync_*() built-ins.
However, since then, icu was changed and is now able to use C++11
atomics, or even no atomic operations at all. In fact, icu will:
* If possible, it will use C++11 atomics, which internally rely on
the __atomic built-ins. These are available since gcc 4.7, and all
architectures provide it. On some architectures, you *must* link
with libatomic, on some other architectures, they are available
built-in, but in all cases, linking against libatomic does not
harm. Thanks to this, even ARC with no atomic support (which was
the original reason for adding the BR2_ARCH_HAS_ATOMICS) dependency
builds fine, provided -latomic is added to LIBS.
* If C++11 atomics are not available, then it falls back to
__sync_*() built-ins, which allows compilers older than 4.7 to be
supported.
* If really no atomic mechanism is available, then it falls back to a
basic implementation based on a mutex.
Conclusion:
- The BR2_ARCH_HAS_ATOMICS dependency is no longer needed.
- We need to link with -latomic when gcc >= 4.7 is used.
Note that reverse dependencies of icu are also changed accordingly.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To use webchannel in an application qwebchannel.js is needed but this file was not
installed.
Signed-off-by: Julien Corjon <corjon.j@ecagroup.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
[Thomas:
- order packages alphabetically
- use tabs for indentation in Config.in
- add missing BR2_PACKAGE_QT5_JSCORE_AVAILABLE dependency for the
comment.]
Signed-off-by: Peter Seiderer <ps.report@gmx.net>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
With OVERRIDE_SRCDIR we don't apply any of the qt5base patches, but the
custom specs files are needed to be able to build - So install these in the
configure step instead of having them as a patch.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
This is the only package where we select directfb. Change it to use depends
on to match what we do for the X11 backend.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Currently Qt 5.5 only detects and build the eglfs_mali device
integration if the commercial Mali driver package from ARM is used.
This patch makes sure the Qt configure script also test for the
sunxi-mali driver package. It also removes the dependency of
the proprietary fbdev_window.h.
This issue is set to be fixed in upcoming Qt 5.6:
https://codereview.qt-project.org/#/c/125837/
[Thomas: renumber patch from 0010 to 0009.]
Signed-off-by: Daniel Nyström <daniel.nystrom@timeterminal.se>
Tested-by: Ariel D'Alessandro <ariel@vanguardiasur.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Tested-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
[Thomas: build tested before the patch, verified that indeed the
eglfs-mali plugin doesn't get built, and that after the patch it gets
built as expected.]
The gstreamer 0.10 support code seems to have bitrotten as the build fails
with undefined references to various functions:
.obj/qgstreameraudiodecodersession.o: In function `QGstreamerAudioDecoderSession::read()':
qgstreameraudiodecodersession.cpp:(.text+0x13a0): undefined reference to `QGstUtils::audioFormatForBuffer(_GstBuffer*)'
collect2: error: ld returned 1 exit status
Makefile:111: recipe for target '../../../../plugins/mediaservice/libgstaudiodecoder.so' failed
make[6]: *** [../../../../plugins/mediaservice/libgstaudiodecoder.so] Error 1
Makefile:45: recipe for target 'sub-audiodecoder-make_first' failed
make[5]: *** [sub-audiodecoder-make_first] Error 2
make[5]: *** Waiting for unfinished jobs....
.obj/qgstreamercapturesession.o: In function `QGstreamerCaptureSession::probeBuffer(_GstBuffer*) [clone .part.30]':
qgstreamercapturesession.cpp:(.text+0x3fc8): undefined reference to `QGstUtils::bufferToImage(_GstBuffer*)'
collect2: error: ld returned 1 exit status
Makefile:153: recipe for target '../../../../plugins/mediaservice/libgstmediacapture.so' failed
make[6]: *** [../../../../plugins/mediaservice/libgstmediacapture.so] Error 1
Makefile:95: recipe for target 'sub-mediacapture-make_first' failed
make[5]: *** [sub-mediacapture-make_first] Error 2
.obj/qgstreamerplayersession.o: In function `QGstreamerPlayerSession::QGstreamerPlayerSession(QObject*)':
qgstreamerplayersession.cpp:(.text+0xecc): undefined reference to `gst_video_connector_get_type'
.obj/qgstreamerplayersession.o: In function `QGstreamerPlayerSession::processBusMessage(QGstreamerMessage const&)':
qgstreamerplayersession.cpp:(.text+0x5b4c): undefined reference to `QGstUtils::gstTagListToMap(_GstStructure const*)'
collect2: error: ld returned 1 exit status
Makefile:129: recipe for target '../../../../plugins/mediaservice/libgstmediaplayer.so' failed
make[6]: *** [../../../../plugins/mediaservice/libgstmediaplayer.so] Error 1
Makefile:70: recipe for target 'sub-mediaplayer-make_first' failed
make[5]: *** [sub-mediaplayer-make_first] Error 2
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Update the already existing fix for EGL/X11 header issue to fix
an additional problem encountered on my system where I had
compile errors in qeglplatformscreen.cpp. The problem was related
to the wrong order of includes. The X11 headers must always be
included last, as indicated in
http://lists.qt-project.org/pipermail/development/2013-March/010511.html
The fix is done in the existing 0003-xcb-egl-fixes.patch patch, since
it is an additional fix for the same problem.
[Thomas: tweak commit log, and adjust SoB details as suggested by
Arnout.]
Signed-off-by: Marc Andre <marc.andre@netline.ch>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The new DirectFB version does not build with gcc 4.3 from the Blackfin
toolchain. One of the reason is that va_copy has some issues, which
were fixed in gcc 4.4.0
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36799). There are also
some other issues, which were fixed by a patch proposed by Peter
Seiderer at
http://lists.busybox.net/pipermail/buildroot/2015-February/120281.html.
However, it probably doesn't make a lot of sense to carry patches that
are not upstream for such old compilers. Instead, this commit takes
the action of making DirectFB available only on toolchains using gcc
>= 4.5, which was tested with the Arago toolchain. gcc 4.4 could
potentially work, but wasn't tested (it is no longer supported by the
internal toolchain backend, and we don't have any toolchain based on
gcc 4.4), so we take the safe decision of requiring at least gcc 4.5.
[Peter: add comment explaining toolchain dependenc as suggested by Vincente]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
