Add support to build the ACPICA package for the host. This is useful
for the iasl command which is required to build some packages,
including Xen tools.
This is a necessary requirement before changing the Xen package to
address:
http://autobuild.buildroot.net/results/afa199864d6b546fe759bb582a9c10702ea7fa78/
Signed-off-by: Alistair Francis <alistair.francis@xilinx.com>
Acked-by: Erico Nunes <nunes.erico@gmail.com>
[Thomas: use PREFIX= and not DESTDIR= for host installation, tweak
commit log.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
m68k coldfire causes ffmpeg to think atomic intrinsics are available,
so ffmpeg doesn't use its fallback on pthreads based atomic
operations. However, m68k coldfire doesn't provide properly working
sync 4 atomics, causing a build failure.
Since fixing ffmpeg on m68k coldfire is not really important (who
wants to use ffmpeg on such platform?), we simply disallow the
selection of ffmpeg on this platform.
Alternate approaches have been proposed in the past:
- Bernd Kuhls proposed in http://patchwork.ozlabs.org/patch/766909/
to add a dependency on BR2_TOOLCHAIN_HAS_SYNC_4, but this is wrong
because other architectures that lack sync 4 atomics, such as
Sparc, can build ffmpeg perfectly fine thanks to the pthreads based
fallback code.
- Waldemar Brodkorb proposed in
https://patchwork.ozlabs.org/patch/756664/ to add an explicit
option in ffmpeg configure to force the use of pthreads based
atomics. However, we believe that running ffmpeg on m68k coldfire
is such an unlikely use case that it isn't worth carrying a patch
for this.
Fixes:
http://autobuild.buildroot.net/results/b3e/b3eaaf6d73cd49f5919143aeaa5cbb4d15a7ccc3/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The gnutils code uses __attribute__((constructor)) and
__attribute__((destructor)) to call constructor/desctructor when a
shared library is loaded.
Constructor/desctructor are not used when a static library is used
(except when if -Wl,--whole-archive -lgnutls -Wno-whole-archive is
used, not tested).
Even if gnutls initialization (_gnutls_global_init()) may be
called manually, the gnutls maintainer said it's not supported [1].
"Note that static linking applications with gnutls is not something
supported. gnutls relies on library constructors and destructors
which are not loaded when linking statically."
Now the gnutls script warns about static linking [2].
So disable gnutls statically by adding "depends on !BR2_STATIC_LIBS"
at Kconfig level and --disable-static in GNUTLS_CONF_OPTS.
Fixes:
[taskd] http://autobuild.buildroot.net/results/c2d/c2dd5c1c9dc87d2943c15e58ee56e67d7375368c
[ffmpeg] http://autobuild.buildroot.net/results/892/8926d319d6d1cd1ee72239ad7d9ca869d2355628
[sngrep] http://autobuild.buildroot.net/results/f7f/f7fb42d3742f6f01000a0d181e0c785640284405
[1] https://gitlab.com/gnutls/gnutls/issues/203
[2] 6b74888679
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
[Romain: merge our two patches together
add some option comment
disable static libgnutls.a
add sngrep autobuilder reference]
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Tested-by: Bernd Kuhls <bernd.kuhls@t-online.de>
[Thomas: do not disable libgnutls.a]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
As reported by Bernd [1], using POST_EXTRACT to copy
linux_syscall_support.h break the legal-info target when
google-breakpad package is selected:
/usr/bin/install: cannot stat '/home/bernd/buildroot/buildroot/output/ost/usr/i586-buildroot-linux-uclibc/sysroot/usr/include/linux_syscall_support.h': No such file or directory
This is because linux_syscall_support.h is installed by a dependency
of google-breakpad, and dependencies are only guaranteed to be
available for the configure step of a package. To fix this, we use a
PRE_CONFIGURE hook instead of POST_EXTRACT hook.
[1] http://lists.busybox.net/pipermail/buildroot/2017-May/192844.html
Reported-by: Bernd Kuhls <bernd.kuhls@t-online.de>
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
firejail has been marked as broken since 3ad100fdcb
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Cc: Chris Frederick <chrisf@cdf123.net>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Also use bz2 tarball and provide md5 & sha256 hashes.
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The project moved to github, the current download URL is broken:
$ wget -q http://www.msweet.org/files/project3/mxml-2.10.tar.gz
$ file mxml-2.10.tar.gz
mxml-2.10.tar.gz: HTML document, UTF-8 Unicode text, with very long lines
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
ola does not build with current protobuf. Upstream bug report is still open.
https://github.com/OpenLightingProject/ola/issues/1192
Cc: Dave Skok <blanco.ether@gmail.com>
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The project moved to github: http://stella.sourceforge.net/
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
When linking demo_mn_console statically with pcap, the CMake build
system forget to link with other libraries linked with libpcap
(-lnl-genl-3 -lnl-3 -ldbus-1 -pthread).
[100%] Linking C executable demo_mn_console
lib64/libpcap.a(pcap-linux.o): In function nl80211_init': pcap-linux.c:(.text+0x41e): undefined reference tonl_socket_alloc'
To fix this, the build system could use pcap-config:
pcap-config --libs --static
-L/path/to/sysroot/usr/lib -lpcap -L/path/to/sysroot/usr/lib/.libs
-lnl-genl-3 -lnl-3 -L/path/to/sysroot/usr/lib -ldbus-1 -pthread
Also don't use getopt() from contrib directory to avoid a clash with
libc definition.
Fixes:
http://autobuild.buildroot.net/results/f43/f437d09ac6c689c911e1885b95da33b692f2cb3chttp://autobuild.buildroot.net/results/385/3859dc0f4de7e3284a96d5841f040f69f71842dfhttps://github.com/OpenAutomationTechnologies/openPOWERLINK_V2/issues/187
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Tested-by: Bernd Kuhls <bernd.kuhls@t-online.de>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Make sure that libiconv is built before popt when needed.
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Prior to glibc 2.18, definitions like SIZE_MAX or INT_FAST32_MAX from
<stdint.h> were only made available for C code, or in C++ if
__STDC_LIMIT_MACROS was defined.
The code from jasper uses such definitions, without defining
__STDC_LIMIT_MACROS. Unfortunately, defining __STDC_LIMIT_MACROS in
the jasper headers doesn't work, since <stdint.h> has already been
included before, at a point where __STDC_LIMIT_MACROS was not defined.
So to solve this problem, we simply pass -D__STDC_LIMIT_MACROS in
CXXFLAGS when building opencv with jasper support.
This patch uses the same solution used for libraw:
https://git.buildroot.net/buildroot/commit/package/libraw?id=d246cf5fd01bb0d20a0e64194ffed514ea8dd0aa
Fixes:
http://autobuild.buildroot.net/results/095/095f7574afdb633c59a625cd063de03644b6d3a7/
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
When the mono package is installed, the autotools installer installs
the /etc/mono files to the target. A post_install hook then copies
over the mono libraries to the target as well as the host /etc/mono
files which overrides the target files. The target specific mono
configuration file (/etc/mono/config) is overridden with the host
settings. This causes mono on the target to be unable to locate target
specific .so files as it overrides the changes enacted by the patches
for the package.
Signed-off-by: Dustin Johnson <dustin.r.johnson@gmail.com>
Tested-by: Angelo Compagnucci <angelo.compagnucci@gmail.com>
Reviewed-by: Angelo Compagnucci <angelo.compagnucci@gmail.com>
Acked-by: Angelo Compagnucci <angelo.compagnucci@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This commit adds a patch to the libepoxy package to make the EGL
support optional, which allows libepoxy to build with a pure OpenGL
Mesa3D configuration (i.e without EGL/OpenGLES).
Fixes:
http://autobuild.buildroot.net/results/88774af2845e17cab021a72c8f3171fe30b3a1ff/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The configure option controlling bzip2 support got its current name in
2012 with its initial commit:
https://sourceforge.net/p/c-icap/code/890/#diff-2
This patch fixes the configure warning:
configure: WARNING: unrecognized options: [...] --without-bzip2
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The configure option controlling berkeleydb support got its current
name in 2009: https://sourceforge.net/p/c-icap/code/322/
This patch fixes a configure warning:
configure: WARNING: unrecognized options: [...] --without-berkeleydb, [...]
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
CVE-2017-8798: Integer signedness error in MiniUPnP MiniUPnPc v1.4.20101221
through v2.0 allows remote attackers to cause a denial of service or
possibly have unspecified other impact.
For more details including a PoC, see:
https://github.com/tintinweb/pub/tree/master/pocs/cve-2017-8798
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fixes:
CVE-2017-3302 - Crash in libmysqlclient.so in Oracle MySQL before 5.6.21 and
5.7.x before 5.7.5 and MariaDB through 5.5.54, 10.0.x through 10.0.29,
10.1.x through 10.1.21, and 10.2.x through 10.2.3.
CVE-2017-3313 - Vulnerability in the MySQL Server component of Oracle MySQL
(subcomponent: Server: MyISAM). Supported versions that are affected are
5.5.53 and earlier, 5.6.34 and earlier and 5.7.16 and earlier. Difficult to
exploit vulnerability allows low privileged attacker with logon to the
infrastructure where MySQL Server executes to compromise MySQL Server.
Successful attacks of this vulnerability can result in unauthorized access
to critical data or complete access to all MySQL Server accessible data.
CVE-2017-3308 - Vulnerability in the MySQL Server component of Oracle MySQL
(subcomponent: Server: DML). Supported versions that are affected are 5.5.54
and earlier, 5.6.35 and earlier and 5.7.17 and earlier. Easily "exploitable"
vulnerability allows low privileged attacker with network access via
multiple protocols to compromise MySQL Server. While the vulnerability is
in MySQL Server, attacks may significantly impact additional products.
Successful attacks of this vulnerability can result in unauthorized
ability to cause a hang or frequently repeatable crash (complete DOS) of
MySQL Server.
CVE-2017-3309 - Vulnerability in the MySQL Server component of Oracle MySQL
(subcomponent: Server: Optimizer). Supported versions that are affected are
5.5.54 and earlier, 5.6.35 and earlier and 5.7.17 and earlier. Easily
"exploitable" vulnerability allows low privileged attacker with network
access via multiple protocols to compromise MySQL Server. While the
vulnerability is in MySQL Server, attacks may significantly impact
additional products. Successful attacks of this vulnerability can result
in unauthorized ability to cause a hang or frequently repeatable crash
(complete DOS) of MySQL Server.
CVE-2017-3453 - Vulnerability in the MySQL Server component of Oracle MySQL
(subcomponent: Server: Optimizer). Supported versions that are affected are
5.5.54 and earlier, 5.6.35 and earlier and 5.7.17 and earlier. Easily
"exploitable" vulnerability allows low privileged attacker with network
access via multiple protocols to compromise MySQL Server. Successful attacks
of this vulnerability can result in unauthorized ability to cause a hang or
frequently repeatable crash (complete DOS) of MySQL Server.
CVE-2017-3456 - Vulnerability in the MySQL Server component of Oracle MySQL
(subcomponent: Server: DML). Supported versions that are affected are 5.5.54
and earlier, 5.6.35 and earlier and 5.7.17 and earlier. Easily "exploitable"
vulnerability allows high privileged attacker with network access via
multiple protocols to compromise MySQL Server. Successful attacks of this
vulnerability can result in unauthorized ability to cause a hang or
frequently repeatable crash (complete DOS) of MySQL Server.
CVE-2017-3464 - Vulnerability in the MySQL Server component of Oracle MySQL
(subcomponent: Server: DDL). Supported versions that are affected are 5.5.54
and earlier, 5.6.35 and earlier and 5.7.17 and earlier. Easily "exploitable"
vulnerability allows low privileged attacker with network access via
multiple protocols to compromise MySQL Server. Successful attacks of this
vulnerability can result in unauthorized update, insert or delete access to
some of MySQL Server accessible data.
And a number of important, but non-security related fixes:
MDEV-12602: Fixed some race conditions in InnoDB encryption
MariaDB Backup alpha introduced
Galera wsrep library updated to 25.3.20
For details, see the release notes:
https://mariadb.com/kb/en/mariadb/mariadb-10123-release-notes/
[Peter: drop COPYING.LESSER and add a reference to the bugtracker issue
explaining why]
Signed-off-by: Ryan Coe <bluemrp9@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fixes:
- CVE-2017-9078: A double-free in the server could be triggered by an
authenticated user if dropbear is running with -a (Allow connections to
forwarded ports from any host) This could potentially allow arbitrary code
execution as root by an authenticated user. Affects versions 2013.56 to
2016.74. Thanks to Mark Shepard for reporting the crash.
- CVE-2017-9079: Dropbear parsed authorized_keys as root, even if it were a
symlink. The fix is to switch to user permissions when opening
authorized_keys.
A user could symlink their ~/.ssh/authorized_keys to a root-owned file
they couldn't normally read. If they managed to get that file to contain
valid authorized_keys with command= options it might be possible to read
other contents of that file. This information disclosure is to an already
authenticated user. Thanks to Jann Horn of Google Project Zero for
reporting this.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
In configuration where target architecture == host architecture, and
libgpg-error is installed system-wide with development files, the build
of cppcms fails with:
/home/test/buildroot/output/host/usr/bin/x86_64-amd-linux-gnu-g++ --sysroot=/home/test/buildroot/output/host/usr/x86_64-buildroot-linux-gnu/sysroot -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Os -Wall -Wextra -DNDEBUG CMakeFiles/base64_test.dir/tests/base64_test.cpp.o -o base64_test -L/home/test/buildroot/output/host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib -Wl,-rpath,/home/test/buildroot/output/build/cppcms-1.0.5:/home/test/buildroot/output/build/cppcms-1.0.5/booster:/usr/lib -rdynamic libcppcms.so.1.0.5 booster/libbooster.so.0.0.3 -lpthread /home/test/buildroot/output/host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libpcre.so /home/test/buildroot/output/host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libgcrypt.so /home/test/buildroot/output/host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libdl.so /home/test/buildroot/output/host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libz.so
/home/test/buildroot/output/host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libgcrypt.so: undefined reference to `gpg_err_set_errno@GPG_ERROR_1.0'
/home/test/buildroot/output/host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libgcrypt.so: undefined reference to `gpgrt_lock_init@GPG_ERROR_1.0'
/home/test/buildroot/output/host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libgcrypt.so: undefined reference to `gpgrt_lock_destroy@GPG_ERROR_1.0'
/home/test/buildroot/output/host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libgcrypt.so: undefined reference to `gpg_err_code_from_syserror@GPG_ERROR_1.0'
/home/test/buildroot/output/host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libgcrypt.so: undefined reference to `gpg_err_code_from_errno@GPG_ERROR_1.0'
/home/test/buildroot/output/host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libgcrypt.so: undefined reference to `gpgrt_lock_unlock@GPG_ERROR_1.0'
/home/test/buildroot/output/host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libgcrypt.so: undefined reference to `gpg_strerror@GPG_ERROR_1.0'
/home/test/buildroot/output/host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libgcrypt.so: undefined reference to `gpg_strsource@GPG_ERROR_1.0'
/home/test/buildroot/output/host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libgcrypt.so: undefined reference to `gpgrt_lock_lock@GPG_ERROR_1.0'
The problem comes from the
"-Wl,-rpath,/home/test/buildroot/output/build/cppcms-1.0.5:/home/test/buildroot/output/build/cppcms-1.0.5/booster:/usr/lib"
option, which tells the linker to search for libraries in /usr/lib.
This commit fixes that by asking CMake to not add any rpath when
building cppcms.
Fixes:
http://autobuild.buildroot.net/results/a7eb1ede552ae14f409cfd7bd877bcf25ca69a74/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fixes#9871
gzip reads default command line options from the environment variable GZIP.
The fbgrab Makefile internally also uses a GZIP make variable to know what
command to use to compress the manpage. Unfortunaly make will export the
value of this make variable to the environment if GZIP is already present in
the enviroment, confusing gzip (as 'gzip' isn't a valid command line argument).
This can either be triggered by users having GZIP set in their environment
(E.G. for custom options), or by enabling BR2_REPRODUCIBLE, where we use
this feature to force the -n option (to not store name/timestamp) to gzip.
We don't really need to compress the manpage as it isn't installed anyway,
so work around the issue by only building the fbgrab application.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Previously was defined in qmi-util.h to fix musl
compatibility. It was missed that this is a shared
header which causes other dependent package builds
to fail, so the static definition was moved into the
implementation where it was used.
Upstream bug report has been updated and this resolves
the following autobuilder related failures.
http://autobuild.buildroot.net/results/fe9b6b1b1399a4e8aafc6a326c81ec97c2480025http://autobuild.buildroot.net/results/40eef797b4d8d53fc6e10f2048316d63549caf6d
test-pkg testing was performed against 10 random toolchains
++ Config snippet ++
BR2_ROOTFS_DEVICE_CREATION_DYNAMIC_EUDEV=y
BR2_PACKAGE_MODEM_MANAGER_LIBQMI=y
BR2_PACKAGE_MODEM_MANAGER=y
BR2_PACKAGE_LIBQMI=y
++ Tested Toolchains ++ (Verified I hit all libc variants)
br-arm-cortex-a9-musl
br-arm-full-static
br-m68k-68040-full (uclibc)
br-mips32r6-el-hf-glibc
br-mips64-n64-full
br-mips64r6-el-hf-glibc
br-mipsel-o32-full
br-sparc64-glibc
linaro-arm
sourcery-arm
Signed-off-by: Matthew Weber <matthew.weber@rockwellcollins.com>
Tested-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
rabbitmq-c currently fails to build in a number of static linking
situations, due to two issues:
- CMake FindOpenSSL module is buggy. Even though it uses pkg-config,
it doesn't use the information returned by pkg-config, and
therefore doesn't know about second order libraries that need be
part of the link for static linking to succeed. Due to this, -lz is
not passed, and therefore rabbitmq-c fails when linking against
libssl/libcrypto. This issue has been reported to upstream CMake at
https://gitlab.kitware.com/cmake/cmake/issues/16885.
- popt might use libintl, but CMake doesn't know about that. For
autotools based packages, we typically work around this by passing
LIBS=, but CMake apparently has no equivalent to LIBS=.
To workaround this, we only use the OpenSSL and Popt optional
dependencies in dynamic linking situations.
Fixes:
http://autobuild.buildroot.net/results/798dbe5e5fd0463bb2066cb115656795144c327f/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fixes [1]:
main.cpp:(.text._ZN11QQmlPrivate10createIntoI6FbItemEEvPv[_ZN11QQmlPrivate10createIntoI6FbItemEEvPv]+0x18): undefined reference to `QQuickFramebufferObject::QQuickFramebufferObject(QQuickItem*)'
.obj/main.o: In function `QQmlPrivate::QQmlElement<FbItem>::~QQmlElement()':
main.cpp:(.text._ZN11QQmlPrivate11QQmlElementI6FbItemED2Ev[_ZN11QQmlPrivate11QQmlElementI6FbItemED5Ev]+0x5c): undefined reference to `vtable for QQuickFramebufferObject'
.obj/main.o: In function `QQmlPrivate::QQmlElement<FbItem>::~QQmlElement()':
main.cpp:(.text._ZN11QQmlPrivate11QQmlElementI6FbItemED0Ev[_ZN11QQmlPrivate11QQmlElementI6FbItemED0Ev]+0x64): undefined reference to `vtable for QQuickFramebufferObject'
.obj/main.o:(.data.rel.ro._ZTVN11QQmlPrivate11QQmlElementI6FbItemEE[_ZTVN11QQmlPrivate11QQmlElementI6FbItemEE]+0x48): undefined reference to `QQuickFramebufferObject::isTextureProvider() const'
.obj/main.o:(.data.rel.ro._ZTVN11QQmlPrivate11QQmlElementI6FbItemEE[_ZTVN11QQmlPrivate11QQmlElementI6FbItemEE]+0x4c): undefined reference to `QQuickFramebufferObject::textureProvider() const'
.obj/main.o:(.data.rel.ro._ZTVN11QQmlPrivate11QQmlElementI6FbItemEE[_ZTVN11QQmlPrivate11QQmlElementI6FbItemEE]+0xb4): undefined reference to `QQuickFramebufferObject::geometryChanged(QRectF const&, QRectF const&)'
.obj/main.o:(.data.rel.ro._ZTVN11QQmlPrivate11QQmlElementI6FbItemEE[_ZTVN11QQmlPrivate11QQmlElementI6FbItemEE]+0xb8): undefined reference to `QQuickFramebufferObject::updatePaintNode(QSGNode*, QQuickItem::UpdatePaintNodeData*)'
.obj/main.o:(.data.rel.ro._ZTVN11QQmlPrivate11QQmlElementI6FbItemEE[_ZTVN11QQmlPrivate11QQmlElementI6FbItemEE]+0xbc): undefined reference to `QQuickFramebufferObject::releaseResources()'
.obj/moc_fbitem.o: In function `FbItem::qt_metacast(char const*)':
moc_fbitem.cpp:(.text+0x70): undefined reference to `QQuickFramebufferObject::qt_metacast(char const*)'
.obj/moc_fbitem.o: In function `FbItem::qt_metacall(QMetaObject::Call, int, void**)':
moc_fbitem.cpp:(.text+0x80): undefined reference to `QQuickFramebufferObject::qt_metacall(QMetaObject::Call, int, void**)'
.obj/moc_fbitem.o: In function `FbItem::~FbItem()':
moc_fbitem.cpp:(.text._ZN6FbItemD2Ev[_ZN6FbItemD5Ev]+0x38): undefined reference to `vtable for QQuickFramebufferObject'
.obj/moc_fbitem.o: In function `FbItem::~FbItem()':
moc_fbitem.cpp:(.text._ZN6FbItemD0Ev[_ZN6FbItemD0Ev]+0x40): undefined reference to `vtable for QQuickFramebufferObject'
.obj/moc_fbitem.o:(.data.rel.ro+0x8): undefined reference to `typeinfo for QQuickFramebufferObject'
.obj/moc_fbitem.o:(.data.rel.ro+0x58): undefined reference to `QQuickFramebufferObject::isTextureProvider() const'
.obj/moc_fbitem.o:(.data.rel.ro+0x5c): undefined reference to `QQuickFramebufferObject::textureProvider() const'
.obj/moc_fbitem.o:(.data.rel.ro+0xc4): undefined reference to `QQuickFramebufferObject::geometryChanged(QRectF const&, QRectF const&)'
.obj/moc_fbitem.o:(.data.rel.ro+0xc8): undefined reference to `QQuickFramebufferObject::updatePaintNode(QSGNode*, QQuickItem::UpdatePaintNodeData*)'
.obj/moc_fbitem.o:(.data.rel.ro+0xcc): undefined reference to `QQuickFramebufferObject::releaseResources()'
.obj/moc_fbitem.o:(.data.rel.ro+0xf0): undefined reference to `QQuickFramebufferObject::staticMetaObject'
[1] http://autobuild.buildroot.net/results/64a/64a198397736db12b73c1f693dbe1c47d73b53da
Signed-off-by: Peter Seiderer <ps.report@gmx.net>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The protobuf library uses atomic intrinsics, so we need to link
against libatomic.
Fixes the build of protobuf on Sparc:
http://autobuild.buildroot.net/results/f3d76eaebd529a61bce849e355182c60f233ed06/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Boost fails to build with the following error:
error: Tried to build the target twice, with property sets having
error: these incompatible properties:
error:
error: - <runtime-link>static <warnings>all
error: - <runtime-link>shared <warnings>on
when the following conditions are met:
- BR2_STATIC_LIBS=y
- BR2_PACKAGE_ICU=y
- BR2_PACKAGE_BOOST_LOCALE=y
- Another BR2_PACKAGE_BOOST_xyz option is enabled, which enables a
feature not provided just by header files, but that requires
building a library.
In such a situation, Boost absolutely wants to build the libboost
libraries as shared libraries. Not having boost-locale, or not having
icu is sufficient to avoid the issue.
So, as a simple work-around, we prevent from building boost-locale
when icu and static linking are used.
Fixes:
http://autobuild.buildroot.net/results/c8f7aa85f5791d8ae8cf4b9085788adc5152286f/
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Cc: Yegor Yefremov <yegorslists@googlemail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
[Thomas:
- only disable boost-locale when icu is enabled
- improve commit log]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
