Currently, `--version` option is used and later matched with a regex to get
the actual gcc version. There's a dedicated gcc option to do exactly that:
`-dumpversion`.
Also `--version` may return a string customised by a vendor that provides
the toolchain, which makes the current regex approach error prone. In
fact, this situation has been seen with a real customised toolchain.
Signed-off-by: Krzysztof Konopko <kris@youview.com>
Signed-off-by: Tomasz Szkutkowski <tomasz.szkutkowski@youview.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
(cherry picked from commit 06cd604ec6)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Building sngrep with OpenSSL support in static linking configurations
currently fails due to undefined symbols in the OpenSSL library. It's
the usual problem with using AC_CHECK_LIB() to discover libraries
instead of the pkg-config based PKG_CHECK_MODULES().
Therefore, this commit introduces a patch that switches to using
pkg-config to discover OpenSSL. A preliminary patch is needed, without
which appending to LIBS/CFLAGS doesn't work. Both patches have been
submitted upstream.
Fixes:
http://autobuild.buildroot.net/results/911143de823b2c749ac0a59dfa06adb6ddd3de50/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
(cherry picked from commit bfd273d83a)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This commit cherry-picks an upstream patch that fixes a compile error
that was introduced in v2.1.1
Signed-off-by: Kurt Van Dijck <dev.kurt@vandijck-laurijssen.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
(cherry picked from commit f80fc852a3)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Mosquitto combined with version 2.1.0 of libwebsockets yields a failing
system. Version 2.1.1 restores the websocket interface again.
Signed-off-by: Kurt Van Dijck <dev.kurt@vandijck-laurijssen.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
(cherry picked from commit 71d54786a3)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fixes:
GNUTLS-SA-2017-3A - Addressed integer overflow resulting to invalid
memory write in OpenPGP certificate parsing.
GNUTLS-SA-2017-3B - Addressed crashes in OpenPGP certificate parsing,
related to private key parser. No longer allow OpenPGP certificates
(public keys) to contain private key sub-packets.
GNUTLS-SA-2017-3C - Addressed large allocation in OpenPGP certificate
parsing, that could lead in out-of-memory condition.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
(cherry picked from commit 6fdb2b109b)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fixes a buffer-overrun in Bengali.
Switch to https URL to avoid a small delay in protocol redirection.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
(cherry picked from commit 7bbdd9afa4)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The location at ftp.csx.cam.ac.uk only stores 2 latest versions of PCRE.
This results in old (2015.11 and older currently) buildroot versions
timing out on wget several times and having to retrieve the package
from sources.buildroot.org afterwards.
Signed-off-by: Oleg Kitain <okitain@ya.ru>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
(cherry picked from commit 6d7644df70)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This reverts commit bf1c9828f2.
This commit was part of the Kodi 17 series and was committed too early,
current Kodi 16 is incompatible with this bump and needs to be
reverted, fixes https://bugs.busybox.net/show_bug.cgi?id=9711
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
(cherry picked from commit 9642d9589c)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This reverts commit 2ac3045453.
This commit was part of the Kodi 17 series and was committed too early,
current Kodi 16 is incompatible with this bump and needs to be
reverted, fixes https://bugs.busybox.net/show_bug.cgi?id=9711
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
(cherry picked from commit 3e05aa6f53)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
gdk-pixbuf-loader support is enabled by default but it silently fail to
generate gdk-pixbuf.loaders file when host != target.
For exemple on ARM target:
output/host/usr/bin/gdk-pixbuf-query-loaders ./libpixbufloader-svg.la
g_module_open() failed for output/build/librsvg-2.40.16/gdk-pixbuf-loader/./libpixbufloader-svg.la: output/build/librsvg-2.40.16/gdk-pixbuf-loader/./.libs/libpixbufloader-svg.so: wrong ELF class: ELFCLASS32
But it doesn't break the build.
When host = target using the Sourcery CodeBench AMD64 2016.11 toolchain
optimized for x86_68 AMD Puma/Jaguar or AMD Steamroller, it break the
build due to "Illegal instruction".
output/host/usr/bin/gdk-pixbuf-query-loaders libpixbufloader-svg.la
Illegal instruction (core dumped)
Since this option is broken for cross-compilation, disable it.
Fixes:
http://autobuild.buildroot.net/results/393/393145bc9bcb93d6df55ec8c63725c3d9a299957
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
(cherry picked from commit 7372c80cc5)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The LINES variable is automatically set by bash to represent the number
of lines in the terminal. That variable can be set when the shell
receives SIGWINCH.
If the shell does receive SIGWINCH after our LINES array is filled, the
content of the array is mangled.
Rename the variable to avoid that.
Fixes#9456
Reported-by: George Y. <georgebrmz@oss3d.com>
Reported-by: Paul Stewart <paulstewartis@gmail.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Arnout Vandecappelle <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
(cherry picked from commit 00d34e8a6f)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
mpd package fails for both internal and external ARC toolchain as check
for pthread support fails. Such checks fails because _REENTRANT flag is
not defined in gcc even when -pthread is passed.
So we add patch to gcc that defines _REENTRANT on ARC when -pthread is
passed.
Also it disables mpd package for external ARC toolchain as it fails due
to the same issue.
This patch should be reverted as soon as the patch for GCC becomes a
part of ARC toolchain.
Fixes:
http://autobuild.buildroot.net/results/7d7/7d70b62ad996830fbeca46dffcc7a1dc030e575d//
Signed-off-by: Vlad Zakharov <vzakhar@synopsys.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
(cherry picked from commit 4d3556662d)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The libsidplay2 package build system is completely broken. It is made
of a top-level configure script, which calls into sub-configure
scripts in sub-directories. However, since it doesn't use the autoconf
provided AC_CONFIG_SUBDIRS() mechanism, an "autoreconf" doesn't
recurse into the subdirectories.
Due to this, the aclocal.m4 in the libsidplay/ subdirectory doesn't
get re-generated when Buildroot autoreconfs the package. However,
since we patch one of the .m4 files in this subdirectory, when build
time comes, the package notices its aclocal.m4 is older than one of
the .m4 file, and triggers an automatic autoreconf.
Since <pkg>_AUTORECONF = YES is enabled, this automatic autoreconf
works fine: host-autoconf and host-automake are available.
Expect that on powerpc64le, we patch the configure script itself to
make it recognize powerpc64le. But this patching of the configure
script itself gets overwritten by the automatic autoreconf at the
beginning of the build step, causing the build to fail on powerpc64le.
Switching to AC_CONFIG_SUBDIRS() would allow to fix this, but
libsidplay2 needs to pass custom configure options to each of the
sub-configure scripts, something that AC_CONFIG_SUBDIRS() doesn't
support. And since libsidplay2 upstream looks completely dead, the
incentive to fix the whole thing is very limited.
Since what's broken is the autoreconfiguration of the package, what we
do is modify patch 0001-sidplay2-libs-2.1.1.patch to directly tweak the
configure script (instead of the relevant .m4 file). Thanks to this,
<pkg>_AUTORECONF = YES is no longer needed, the .m4 file is no longer
newer than the sub-configure script, and no automatic autoreconf
triggers at build time. This allows the package to build properly on
powerpc64le.
While we normally don't like patching 'configure' scripts directly, in
this case the size of the change in the configure script is very small,
and as explained above, the incentive to fix the package properly is
very limited.
In detail, the changes:
* Patch 0001-sidplay2-libs-2.1.1.patch is turned into a Git-formatted
patch
* The irrelevant changes to Makefile.in files, aclocal.m4, config.h.in,
sidint.h are removed.
* The change to my_macros.m4 is applied directly to the corresponding
configure script.
* The change to the configure.ac script regarding libdir is applied
directly to the corresponding configure script.
* The change to the configure.ac script regarding "*-k*bsd*-gnu" is
dropped, since we don't care about kFreeBSD support.
* LIBSIDPLAY2_AUTORECONF = YES is dropped from the .mk file.
Fixes:
http://autobuild.buildroot.net/results/1f6a42bfece24e09c9c7f4078d549ec5c099c89d/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Tested-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
(cherry picked from commit df1b6d8cb2)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The ncftp build process tries to build and run a small program called
ccdv to beautify the build process output. If it manages to build and
run it, then it uses it.
Unfortunately, this doesn't work well when the target architecture is
close to the host architecture, but not exactly the same. Because both
architectures are close to each other, the test run of ccdv succeeds,
but real use of ccdv during ncftp build process causes an Illegal
instruction issue.
This for example happens with the CodeSourcery AMD64 toolchain, on a
build machine running an i7-4600U, and has been detected in the
autobuilders since the CodeSourcery AMD64 toolchain was upgraded at
the end of January:
http://autobuild.buildroot.net/?reason=ncftp-3.2.6
The issue was also reported by Christopher Arguin back in July 2016:
http://lists.busybox.net/pipermail/buildroot/2016-July/168026.html
and at the time, we identified that simply disabling the ccdv tool, by
passing --disable-ccdv, was enough to solve the issue. But Christopher
never submitted the patch, so the problem remained unfixed.
Therefore, we pass --disable-ccdv to the configure script, which
fixes:
http://autobuild.buildroot.net/results/6eadad0e879ca70bb07b13b4196d42c64b11699f/
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>
(cherry picked from commit 9647c3c5e9)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The iso9660 generation for grub2 assumes that grub-eltorito.img is
available. However, this image is only available for the i386-pc target
(i.e. legacy BIOS). An EFI-bootable iso9660 requires a different layout.
Since we currently can't generate the EFI-bootable iso9660 layout,
require the i386-pc target to be selected in grub.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Reported-by: arnaud.miche@orange.com
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
(cherry picked from commit 3e57fa370c)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
EUMM don't find .xs file in subdirectory (only .pm files are handled)
So, let move lib/GD.xs in the root directory.
Signed-off-by: Francois Perrad <francois.perrad@gadz.org>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
(cherry picked from commit 9475997b24)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This package fails when building with ARC external toolchain
Marking this with special comment "# ARC toolchain issue" as the package
is to be enabled as soon as the issue with the ARC toolchain is
resolved.
Fixes:
http://autobuild.buildroot.net/results/fb6/fb677a917545adee321bdcd2c2519c81326448c4//
Signed-off-by: Vlad Zakharov <vzakhar@synopsys.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This package fails when building with ARC external toolchain
Marking this with special comment "# ARC toolchain issue" as the package
is to be enabled as soon as the issue with the ARC toolchain is
resolved.
Fixes:
http://autobuild.buildroot.net/results/28a/28a92049a6ceef005787c5779f77ecf3fe8ad642//
Signed-off-by: Vlad Zakharov <vzakhar@synopsys.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Commit e482ebf51d attempted to fix the
installation of qt5quickcontrols by only installing the PrivateWidgets
directory for the 5.8.0 version.
However, the availability of PrivateWidgets has nothing to do with the
version; in both 5.6.2 and 5.8.0, the installation is gated by the
following statement in src/src.pro:
qtHaveModule(quick):qtHaveModule(widgets): SUBDIRS += widgets
i.e. it is installed when both the Quick and the Widgets module are
available. The Widgets module is controlled by Buildroot's
BR2_PACKAGE_QT5BASE_WIDGETS symbol, the Quick module is controlled by
Buildroot's BR2_PACKAGE_QT5DECLARATIVE_QUICK. The qt5quickcontrols
package selects BR2_PACKAGE_QT5DECLARATIVE_QUICK so it is not really
needed to include it in the condition. However, it is theoretically
possible to build this package without QtQuick. Also, adding this
condition makes it consistent with src.pro.
Note that commit e482ebf51d introduces a
second fix (not mentioned in the commit message): for version 5.6.2, the
Layouts directory is installed, but in 5.8.0 this directory doesn't
exist any more. Therefore, a separate condition on the version is still
needed.
Fixes:
http://autobuild.buildroot.net/results/1ff3e9ad4ba518d0a37f9fc12038bf9020f28094
Cc: Peter Seiderer <ps.report@gmx.net>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
In commit a75ab1fc1d ("package/classpath:
Don't depend on jamvm"), we removed the dependency of classpath on
jamvm. Since jamvm is only available for a reduced set of architectures,
classpath could until this commit until be built on those architectures.
However, now that this dependency has been removed, classpath can
potentially be built for all architectures supported by Buildroot, even
though it doesn't support all of them.
Since adding support for additional architectures in classpath doesn't
make much sense, because classpath is in Buildroot only usable with
JamVM anyway, and JamVM is only available for a small set of
architectures, this commit simply makes classpath available on the
architectures that it supports.
By doing so, it also removes the or1k support patch which was added by
commit f12a146f81, since anyway or1k is
not supported by JamVM.
Fixes:
http://autobuild.buildroot.net/results/55eb89f89e96b94a821778bc18ed844af08b7460/
(classpath on microblaze)
http://autobuild.buildroot.net/results/279dd731bd9ecf5f9d54bda3715caeaa7cbcdbb3/
(classpath on nios2)
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
On PowerPC64(le), we patch all configure scripts. Due to this, the
version.texi in OpenOCD files gets regenerated, and then since it has
a newer date than openocd.info, openocd build system rebuilds the
documentation. Unfortunately, this documentation rebuild fails on old
machines.
We work around this by faking the date of the generated version.texi
file, to make the build system believe the documentation doesn't need
to be regenerated.
Fixes:
http://autobuild.buildroot.net/results/3cbe65a46e75b8e67846d593884c96df97dec7a4
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Sam Bobroff <sam.bobroff@au1.ibm.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
cmake-3.7 has a bug in how it handles rpath, linking with libraries from
the host.
Until we completely understand the issue, just blacklist cmake-3.7.
The issue has been reported upstream:
http://public.kitware.com/pipermail/cmake/2017-February/064970.html
Reported-by: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Jörg Krause <joerg.krause@embedded.rocks>
Cc: Ben Boeckel <mathstuf@gmail.com>
Cc: Samuel Martin <s.martin49@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
In commit 68cebedeb9 ("assimp: work around
gcc bug on SuperH"), a work around was added to make the package build
with gcc on SuperH. The condition included a test on the gcc version,
which was mistakenly done on the host gcc version, while a test on the
target gcc version was intended.
Thanks to Peter Korsgaard for spotting the issue.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
gcc versions earlier than gcc 6.x fail to build assimp on SuperH when
static linking:
AssxmlExporter.cpp:623:1: error: unable to find a register to spill in class 'GENERAL_REGS'
It's the combination of -Os and *not* having -fPIC that makes gcc
fail, which explains why configurations with dynamic linking work
fine.
-Os -fPIC -> works
-Os -> fails
-O2 -fPIC -> works
-O2 -> works
Therefore, as a workaround, we are forcing the use of -O2 on SuperH
when the gcc version is older than gcc 6.x and we're statically
linking.
Fixes:
http://autobuild.buildroot.net/results/ec88aa8118179e30e24603cc45292047dca19216/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
BR2_TOOLCHAIN_EXTERNAL_BLACKFIN_UCLINUX has been removed in commit
311bc137da ("toolchain: kill ADI
Blackfin toolchain"), so this "depends on" is useless.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Override gcc optimization flags with -O0. The workaround is not required
for gcc6 anymore, so we take this into account into our condition.
Fixes:
http://autobuild.buildroot.net/results/a318f0838a6a602046e719103ac81965c0084d52
Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
[Thomas: add gcc 6.x condition.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
MPlayer doesn't support OpenRISC:
The architecture of your CPU (or1k) is not supported by this configure script
It seems nobody has ported MPlayer to your OS or CPU type yet.
so disable it on this architecture.
Fixes:
http://autobuild.buildroot.net/results/47207dfd10ff6e5ec4ccdcf8454aaf5f408ad1e3/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The python-libconfig package fails to build with musl with very weird
errors coming all the way from Boost Python, which nobody ever
bothered to fix. It's time to disable this package on musl to avoid
the repetitive build failures.
Fixes:
http://autobuild.buildroot.net/results/f0f6cdc8c38c024772615d5e677b0f4ad63ef7ec
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The libuv library uses __sync atomic built-ins:
$ readelf -a -W output/target/usr/lib/libuv.so.1.0.0 | grep __sync
122: 00000000 0 NOTYPE GLOBAL DEFAULT UND __sync_val_compare_and_swap_4
but this is not currently taken into account in the libuv package,
causing some build failures in packages using libuv as an optional
dependency, such as janus-gateway and mosquitto.
Therefore, this commit updates the libuv package with this additional
dependency. The reverse dependencies of libuv are also updated: luv, luvi
and moarvm.
Fixes:
- http://autobuild.buildroot.net/results/bdaa67d763c0d8d377a04529c74f73bee7d4ccef/
(janus-gateway)
- http://autobuild.buildroot.net/results/2bc84ba2d1167018e2d48e5183ead22b6425dcf5/
(mosquitto)
[Peter: drop cmake changes after cmake revert]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
htop wants to use backtrace() support from the C
library. Unfortunately, with old uClibc versions such as the one we
use for the ARC architecture, the backtrace() implementation is in
libubacktrace. In addition, this implementation needs dladdr()
support, which is in libdl, not available when static linking.
Since this problem no longer exists in more recent versions of uClibc,
we simply special case the ARC+static linking case, and make the
configure script believe that <execinfo.h> is not available.
Fixes:
http://autobuild.buildroot.net/results/cdea351fad7a0f61ddec3e6a141da8da0523a902/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The Buildroot manual documents that <pkg>_CONF_ENV is passed in the
environment when calling cmake during the configure step. However, the
actual implementation in pkg-cmake passes HOST_<pkg>_CONF_ENV when
configuring the host variant of a cmake package, but does not pass
<pkg>_CONF_ENV when configuring the target variant of a cmake package.
This commit fixes that by passing <pkg>_CONF_ENV in the environment as
expected. It should not cause any behavior change, because this
feature is in fact not used by any package in upstream Buildroot:
$ grep CONF_ENV $(git grep -l cmake-package package/)
package/pkg-cmake.mk:$(2)_CONF_ENV ?=
package/pkg-cmake.mk: $$($$(PKG)_CONF_ENV) $$(BR2_CMAKE) $$($$(PKG)_SRCDIR) \
package/pkg-cmake.mk: $$($$(PKG)_CONF_ENV) $$(BR2_CMAKE) $$($$(PKG)_SRCDIR) \
This issue was reported by Olivier <ovalentin@awox.com> as bug #9616.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
cmake 3.7 causes serious regressions in some cmake-based packages,
related to how RPATH is handled.
This reverts commit 1ffcf364b6.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Cc: Samuel Martin <s.martin49@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Jörg Krause <joerg.krause@embedded.rocks>
Cc: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
cmake 3.7 causes serious regressions in some cmake-based packages,
related to how RPATH is handled.
This reverts commit d96fafc3d3.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Cc: Samuel Martin <s.martin49@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Jörg Krause <joerg.krause@embedded.rocks>
Cc: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
cmake 3.7 causes serious regressions in some cmake-based packages,
related to how RPATH is handled.
This reverts commit b754237520.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Cc: Samuel Martin <s.martin49@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Jörg Krause <joerg.krause@embedded.rocks>
Cc: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
cmake 3.7 causes serious regressions in some cmake-based packages,
related to how RPATH is handled.
This reverts commit f8a6990c92.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Cc: Samuel Martin <s.martin49@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Jörg Krause <joerg.krause@embedded.rocks>
Cc: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
DirectFB is written in C++, but can be linked to by a C library or
program.
When doing shared link, this is fine because the linker gets help from
the DT_NEEDED flags and knows what libraries to pull in during the link.
However, during a static link, the linker does not get such help.
Properly fixing this would require that there is support in pkg-config
and autotools to specify that the C++ runtime must be linked. Alas there
is no sush support. The only option is to add -lstdc++ to the
Libs.Private field in directfb.pc. But this is not upstreamable, because
there are other C++ runtimes in the wild (e.g. -lc++ from llvm/clang).
However, DirectFB in a static scenario is probably not a very common
scenario.
Disable DirectFB for static builds.
Fixes:
http://autobuild.buildroot.org/results/3d3/3d3036d40ddad71d872d910aae7a24975706d2e9/http://autobuild.buildroot.org/results/d1c/d1c35a6003396942b584f2f2a5e8bf4ac2fbe370/http://autobuild.buildroot.org/results/d45/d4504871bd47930e8363032d380cdfcc5bb8aee7/
[...]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* Remove distribution upgrade cause it slows down the first boot and
presents a bug when executed non interactively.
* Reorganize provision scripts to be in privileged and non privileged
sections
* Add Ubuntu mirror automatic handling for apt packages sources
Fixes bug #9581
Signed-off-by: Angelo Compagnucci <angelo.compagnucci@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The ncurses sub-options BR2_PACKAGE_NCURSES_TARGET_{FORM,MENU,PANEL}
are currently very badly broken: they only control whether the
libform, libmenu and libpanel libraries are installed in
$(TARGET_DIR), but do absolutely nothing about their installation in
$(STAGING_DIR).
This means that when one of those options is disabled, the
corresponding library is indeed not installed in the target, but is
available in staging. It can therefore be detected by the configure
script of another package and used... even though the library will not
be in the target, causing a runtime failure.
Internally, ncurses.mk uses the "make install" logic of ncurses for
the staging installation, but uses a completely hand-written logic for
the target installation, which is the reason for this
desynchronization between what's installed in staging and target.
When BR2_PACKAGE_NCURSES_WCHAR=y, this also causes some build
failures. Indeed, when BR2_PACKAGE_NCURSES_WCHAR=y, Buildroot creates
some symbolic links lib<foo>.so -> lib<foo>w.so in staging and target,
but only for the lib<foo> that have been enabled by
BR2_PACKAGE_NCURSES_TARGET_{FORM,MENU,PANEL}. Due to this, a package
that for example needed the libmenu library but forgot to select
BR2_PACKAGE_NCURSES_TARGET_MENU was:
- Building fine with BR2_PACKAGE_NCURSES_WCHAR disabled (because
libmenu.so exists in staging), but would fail to run at runtime
because libmenu.so is not in the target.
- Fail to build with BR2_PACKAGE_NCURSES_WCHAR=y because only
libmenuw.so exists, and not the libmenu.so symbolic link.
Since those libraries are small (43K for libform, 21K for libmenu and
8.2K for libpanel), this commit takes the very simple approach of
removing those options, and installing the libraries
unconditionally. It therefore uses the "make install" logic for both
the staging *and* target installation.
In detail, this commit:
- Removes the NCURSES_PROGS variable, not needed since
--without-progs already allows to disable the build and
installation of programs.
- Removes the NCURSES_LIBS-y variable, and replaces it with a single
unconditional assignement to NCURSES_LIBS, only used to create the
lib<foo>w.so -> lib<foo>.so symbolic links when wchar support is
enabled.
- Removes NCURSES_INSTALL_TARGET_CMDS and the functions it was
calling: NCURSES_INSTALL_TARGET_LIBS and
NCURSES_INSTALL_TARGET_PROGS.
- Adds a NCURSES_TARGET_SYMLINK_RESET hook to create the reset ->
tset symbolic link, as was done before.
- Adds a NCURSES_TARGET_CLEANUP_TERMINFO to cleanup the terminfo
files in the target, so that we stay in the same situation in terms
of installed terminfo files.
- Removes the BR2_PACKAGE_NCURSES_TARGET_{FORM,MENU,PANEL} options
from the Config.in files: both their definition and usage.
- Simplifies all the symlink dance for lib<foo> -> lib<foo>w, because
as Yann E. Morin suggested, this dance is only needed in staging, not
in the target. Once binaries have been built, they refer to the
SONAME of the library, which is the lib<foo>w variant (for shared
linking). For static linking and .pc files, it's obvious that we
don't care about them on the target. Therefore the
NCURSES_LINK_LIBS_STATIC, NCURSES_LINK_LIBS_SHARED and
NCURSES_LINK_PC functions no longer take any argument: they always
apply to STAGING_DIR only. NCURSES_LINK_TARGET_LIBS is removed.
It is worth mentioning that adding Config.in.legacy support is *NOT*
necessary. Indeed:
- If they were disabled before this patch, having them in
Config.in.legacy would not trigger the legacy warning.
- If they were enabled before this patch, then the behavior is
unchanged: all libraries are now unconditionally installed. So
there is no point in warning the user.
We double-checked the installed size of a filesystem containing just
ncurses before and after this patch, and the only folder that has its
size changed is /usr/lib, growing from 852 KB to 932 KB in the wchar
enabled case. That's a 80 KB system size increase.
This commit fixes the sngrep build failure and potentially numerous
runtime issues with ncurses.
Fixes:
http://autobuild.buildroot.net/results/7b5db21a6c568e6c6c8fe2b5d5a2f5ca24df510c/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
