The update of imx-mkimage in commit
c14d92d439
broke the imx8-bootloader-prepare.sh script for i.MX8M, used in
freescale_imx8mqevk_defconfig
The updated mkimage_fit_atf.sh script in imx-mkimage now needs
a ATF_LOAD_ADDR variable, which was set to 0x00910000 for i.MX8M.
Signed-off-by: Julien Olivain <juju@cotds.org>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
[Thomas: test BR2_PACKAGE_QT5BASE instead of BR2_PACKAGE_QT5, just for
consistency with the package we add to the DEPENDENCIES variable.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
This patch fixes the build issue reported by autobuilder [0].
/home/naourr/work/instance-2/output/build/qt5webkit-5.9.1/Source/WebCore//.obj/platform/leveldb/LevelDBDatabase.o: In function
`WebCore::LevelDBDatabase::openInMemory(WebCore::LevelDBComparator const*)':
LevelDBDatabase.cpp.text._ZN7WebCore15LevelDBDatabase12openInMemoryEPKNS_17LevelDBComparatorE+0x34): undefined reference to `leveldb::NewMemEnv(leveldb::Env*)'
collect2: error: ld returned 1 exit status
make[3]: *** [Makefile.api:97: ../lib/libQt5WebKit.so.5.9.1]
Error 1
The issue happens when both packages leveldb and qt5webkit are enabled.
QtWebKit builds its own copy of leveldb [1] (as a third-party) if the
system does not provided it (i.e. buildroot). It builds it differently
and this is the origin of that issue. Instead of using the Makefile
provided by leveldb [2], QtWebKit uses qmake to build that library [3].
The missing symbol issue happens because the symbol leveldb::NewMemEnv
is bundled in the static library libmemenv.a (aside libleveldb.so).
This static library consists of this single symbol which is like an
extra that is built but *NOT* shipped by default at installation in the
staging directory. Unfortunatly, that symbol is required later by
WebCore [4].
The copy built by QtWebKit is an all-in-one library including both
libleveldb and libmemenv; thus QtWebKit links against libleveldb only.
Also, the linker finds the buildroot's copy first (not the third-party):
that explains why it is complaining about a missing symbol. That copy
does not have the symbol leveldb::NewMemEnv.
Fortunatly, QtWebKit provides a facility to link against the system
leveldb package. The qmake flag WEBKIT_CONFIG+=use_system_leveldb tells
Qt5WebKit to link against libleveldb *AND* libmemenv [5].
To fix that issue, this commit selects the package leveldb that now
installs the libmemenv static library and its header. It ensures that
QtWebKit has everything it needs to be built. It also sets the
appropriate qmake configure flags to tell QtWebKit to use the leveldb
copy built by buildroot instead of the bundled one.
[0]: http://autobuild.buildroot.net/results/46033e82adf592c3b92c6d50cfaf45bd58beeaa4
[1]: https://github.com/qt/qtwebkit/tree/5.9/Source/ThirdParty/leveldb
[2]: https://github.com/qt/qtwebkit/blob/5.9/Source/ThirdParty/leveldb/Makefile#L167-L169
[3]: https://github.com/qt/qtwebkit/blob/5.9/Source/ThirdParty/leveldb/Target.pri#L80
[4]: https://github.com/qt/qtwebkit/blob/5.9/Source/WebCore/platform/leveldb/LevelDBDatabase.cpp#L185
[5]: https://github.com/qt/qtwebkit/blob/5.9/Source/WebCore/WebCore.pri#L254
[6]: 739c25100e
Signed-off-by: Gaël PORTAY <gael.portay@collabora.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
The project's static libraries are not compiled with the -fPIC compiler
flag. This prevents dynamic libraries to link against those libraries.
This commit adds a patch that sets the -fPIC compiler flag to the list of
CFLAGS/CXXFLAGS.
The project now generates position independant code for all of its
outputs (i.e. not limited anymore to its shared libraries).
Fixes:
/home/gportay/src/buildroot/output/host/opt/ext-toolchain/bin/../lib/gcc/x86_64-amd-linux-gnu/6.2.0/../../../../x86_64-amd-linux-gnu/bin/ld: /home/gportay/src/buildroot/output/host/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libmemenv.a(memenv.o): relocation R_X86_64_32S against `.rodata' can not be used when making a shared object; recompile with -fPIC
/home/gportay/src/buildroot/output/host/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libmemenv.a: error adding symbols: Bad value
collect2: error: ld returned 1 exit status
Signed-off-by: Gaël PORTAY <gael.portay@collabora.com>
[Arnout: renumber patch]
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
The project builds a tiny static library that consists of a single
symbol which creates an in-memory LevelDB database.
That library is not installed by default and may be used by other
projects.
This commit installs in the staging directory the libmemenv.a static
library and the memenv.h header file.
Signed-off-by: Gaël PORTAY <gael.portay@collabora.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
BR2_PACKAGE_OPTEE_CLIENT depends on BR2_TOOLCHAIN_HAS_THREADS.
Library teec uses pthread support to protect clients state management.
This change declares this dependency in package optee-client and
updates dependent packages accordingly: optee-benchmark, optee-client,
optee-examples and optee-test.
Fixes [1] and [2] where config selected an toolchain without thread
support and build failed with trace like:
CMake Error at /home/buildroot/autobuild/run/instance-1/output/host/share/cmake-3.8/Modules/FindPackageHandleStandardArgs.cmake:137 (message):
Could NOT find Threads (missing: Threads_FOUND)
Call Stack (most recent call first):
/home/buildroot/autobuild/run/instance-1/output/host/share/cmake-3.8/Modules/FindPackageHandleStandardArgs.cmake:377 (_FPHSA_FAILURE_MESSAGE)
/home/buildroot/autobuild/run/instance-1/output/host/share/cmake-3.8/Modules/FindThreads.cmake:212 (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
libteec/CMakeLists.txt:8 (find_package)
[1] http://autobuild.buildroot.net/results/ed6ffe2197da4f3a970bd3c5522291236396cc8e
[2] http://autobuild.buildroot.net/results/406f90048db097580b626ef889823132f8676ba1
Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>
[Thomas: fix dependencies of Config.in comment, as noticed by Baruch.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
The optee-os package was recently changed to provide the OPTEE_OS_SDK
to allow other packages to locate the OP-TEE Trusted Application SDK,
so let's use this new variable in the optee-examples package.
Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>
[Thomas: use the new variable name, rework commit log]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
The optee-os package was recently changed to provide the OPTEE_OS_SDK
to allow other packages to locate the OP-TEE Trusted Application SDK,
so let's use this new variable in the optee-test package.
Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>
[Thomas: use the new variable name, rework commit log]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
This commit adds a new variable OPTEE_OS_SDK, define by the optee-os
package, which points to the OPTEE SDK installed in STAGING_DIR. This
will allow other pakage to find this SDK more easily.
Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>
[Thomas: improve commit log, rename variable to just OPTEE_OS_SDK]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
If libsoxr is build statically against libavutil other applications
needs to know that they must link with `-lavutil` when building in a
static context.
Signed-off-by: Jörg Krause <joerg.krause@embedded.rocks>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This reverts commit d81870ae81.
The patch attempts to fix static linking with libsoxr when it build with
avutils. The `Libs.private` field should not contain the full absolute path to
the static library, but only the link flags for private libraries, e.g
`-lm`.
Buildroots pkg-config prepends the sysroot to the value found in `Libs.private`
resulting in a malformed linker flag if libavutil is found:
```
-L/home/test/autobuild/run/instance-3/output/host/bin/../arm-buildroot-linux-uclibcgnueabi/sysroot/usr/lib -lsoxr
/home/test/autobuild/run/instance-3/output/host/bin/../arm-buildroot-linux-uclibcgnueabi/sysroot/home/test/autobuild/run/instance-3/output/host/arm-buildroot-linux-uclibcgnueabi/sysroot/usr/lib/libavutil.a
```
.. or if libavutils is not found:
```
-L/home/test/autobuild/run/instance-1/output/host/bin/../arm-buildroot-linux-uclibcgnueabi/sysroot/usr/lib -lsoxr AVUTIL_LIBRARIES-NOTFOUND
```
Revert this commit and replace the patch by a follow-up patch which only
adds `-lavutil` to `Libs.private` in case it is found and used by
libsoxr.
Fixes:
http://autobuild.buildroot.net/results/6eb4e2c9bd3884ab0152ddf873c20e62f0941181/http://autobuild.buildroot.net/results/07207b0a58a08bf7c2cb78345a58244b5e6aab0e/
Signed-off-by: Jörg Krause <joerg.krause@embedded.rocks>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Buildroot built with systemd fails to open a login prompt on the
serial port when /dev/console is specified as BR2_TARGET_GENERIC_GETTY_PORT
(which is its default value):
systemd[1]: dev-console.device: Job dev-console.device/start timed out.
systemd[1]: Timed out waiting for device /dev/console.
systemd[1]: Dependency failed for Serial Getty on console.
systemd[1]: serial-getty@console.service: Job serial-getty@console.service/start failed with result 'dependency'.
systemd[1]: dev-console.device: Job dev-console.device/start failed with result 'timeout'.
systemd[1]: Reached target Login Prompts.
systemd[1]: Reached target Multi-User System.
According to this issue on Github [1], serial-getty@.service should
not be instantiated on /dev/console, console-getty@.service should
be used instead. This stems from the fact that there should be no
dependency on /dev/console.
[1] https://github.com/systemd/systemd/issues/10914
Signed-off-by: Xavier Ruppen <xruppen@gmail.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
[Peter: drop SERVICE variable as suggested by Yann]
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Commit c110e48cec disabled openssl support
on QT 5.6, this has the side-effect of breaking the build of
python-pyqt5 because support of openssl is enabled on python-pyqt5 if
BR2_PACKAGE_OPENSSL is selected
To fix this issue, add a new BR2_PACKAGE_QT5BASE_OPENSSL option in
qt5base and use it in python-pyqt5
Fixes:
- http://autobuild.buildroot.org/results/e92991308d47649cecc4084e41ab5711ec96831f
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
[Peter: make _OPENSSL a blind option, add libressl logic for 5.6.x]
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
LibreSSL build is successful with shared linkage, but not default dlopen().
Also adds patch for successful compilation by using -fpermissive.
Signed-off-by: James Grant <jamesg@zaltys.org>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
