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>
Building with ccache failed with:
Running configuration tests...
Failed to process makespec for platform 'devices/linux-buildroot-g++'
Project ERROR: Compiler <path_to_output_dir>/host/usr/bin/ccache <path_to_output_dir>/host/usr/bin/<cross_compile>-g++ not found. Check the value of CROSS_COMPILE -device-option
Could not read qmake configuration file <path_to_output_dir>/build/qt5base-5.5.0/mkspecs/devices/linux-buildroot-g++/qmake.conf.
Error processing project file: /dev/null
This was caused by Buildroot setting this in
qt5base-5.5.0/mkspecs/devices/linux-buildroot-g++/qmake.conf:
QMAKE_CXX = $${BR_CCACHE} $${CROSS_COMPILE}g++
But qt5base-5.5.0/mkspecs/features/device_config.prf expects QMAKE_CXX
to be a single valid (absolute or QMAKE_PATH_ENV-relative) path to an
existing file, which is not possible if using ccache as above.
Add a patch fixing this by testing only the first value in QMAKE_CXX.
Signed-off-by: Benoît Thébaudeau <benoit@wsystem.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Fix the missing gstreamer1 build dependencies, which could possibly
prevent the configuration of qt5multimedia from detecting the supported
gstreamer1 features.
Fix the missing gstreamer1 install rules, which resulted in the
following runtime error:
defaultServiceProvider::requestService(): no service found for - "org.qt-project.qt.mediaplayer"
Signed-off-by: Benoît Thébaudeau <benoit@wsystem.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Even though we have some specific code to support building Qt5 for
static-only configurations, it doesn't work. The first problem is that
our custom qmake.conf always passes -ldl, which makes a number of Qt5
config.tests fail at configure time. Once this problem is fixed by
removing -ldl from QMAKE_LIBS and adding it to QMAKE_LIBS_DYNLOAD
instead, the next problem is that the plugin infrastructure of Qt5
assumes that Linux has dynamic library support: the qlibrary_unix.cpp
file includes <dlfcn.h>, and the only condition for this file to not
be included is:
Until recently, building Qt5 statically was working because our C
library was not built static-only: it provided <dlfcn.h> and
libdl.so. But now that we have a really static only toolchain, Qt5 no
longer builds.
The easiest solution is to simply make Qt5 depend on dynamic library
support.
Fixes:
http://autobuild.buildroot.net/results/538/538e0325adba9fabbe4ec8e550fbb6a7219f5e7a/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
When the XCB backend is selected, the libqxcb.so plugin is installed,
and is linked against libQt5XcbQpa.so. However, until, Buildroot was
not installing this library. This commit fixes this.
[Thomas: tweak commit log.]
Signed-off-by: Matthew Shyu <matthew.shyu@amlogic.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The workaround implemented in 0001-Force_egl_visual_ID_33.patch has to
be enabled as soon as gpu_vivante/xorg is used. This does not depends
on eglfs option.
[Thomas: minor commit log tweaks.]
Signed-off-by: Jérôme Pouiller <jezz@sysmic.org>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This module loose his GPLv2 licensing option. Remains the LGPLv2.1 with
exception and LGPLv3 as the possible open-source licenses.
Fixes:
http://autobuild.buildroot.net/results/6c80ba0669a7fc8cc60baaa849044fd65a78ce87/
Signed-off-by: Julien Corjon <corjon.j@ecagroup.com>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Since Qt 5.5, those three modules have lost their GPLv2 licensing
option. Remains the LGPLv2.1 with exception and LGPLv3 as the possible
open-source licenses.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
