- Upstream patches removed.
- Do not autoreconf since this was neecessary for one of those patches
that are now upstream. Also remove host-gettext dependency for the
same reason.
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
ERROR: reloc type R_ARM_THM_MOVW_ABS_NC unsupported in this context
ERROR: reloc type R_ARM_THM_MOVT_ABS unsupported in this context
2 bad relocscollect2: error: ld returned 1 exit status
Binutils build fine with -O1, -O2 or -O3.
Reported upstream:
https://sourceware.org/bugzilla/show_bug.cgi?id=20552
Fixes:
http://autobuild.buildroot.net/results/e72/e727e6e9cf361acc786acec192a88f5f5444a2f6
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
libjpeg and jpeg-turo are providers of the jpeg virtual package, so they
must declare themselves as such.
We do not have any problem, because the dependency is computed from the
Kconfig-defined option BR2_PACKAGE_PROVIDES_JPEG, and we do not check
the Makefile-defined <FOO>_PROVIDES variable.
For the sake of correctness, make both libjpeg and jpeg-turo declare
themselves as providers for the jpeg virtual package.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Instead of depending on each provider of cryptodev, make openssl depend
on the virtual package.
This is easy because in both cases the openssl build systems needs the
same configuration options.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
cryptodev-linux and ocf-linux are providers of the cryptodev virtual
package, so they must declare themselves as such.
We do not have any problem for now, as the only consumer (openssl) of
both cryptodev-linux and ocf-linux did not depend on the virtual package
but on each provider. The other consumer is gnutls, but has only a
dependency on cryptodev-linux.
However, openssl can be turned into a proper consumer of the virtual
package, which would trigger the bug.
For the sake of correctness, make both cryptodev-linux and ocf-linux
declare themselves as providers for the cryptodev virtual package.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Dosfstools doesn't build with musl only if BR2_PACKAGE_HAS_UDEV is set
due to a missing include for PATH_MAX (limits.h).
Fixes:
http://autobuild.buildroot.net/results/346/346feda6a4a83850dbb62919eb33482302053490
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
It's remaining from the master-next merge and no longer applies.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
As reported in bug #8206, the mplayer configure script fails to detect
the availability of X11 header/library if the X.org development packages
are not installed on the build machine.
This is due to the logic used by the mplayer configure script, which
looks like this:
for I in $(echo $extra_cflags | sed s/-I//g) /usr/include ; do
if test -f "$I/X11/Xlib.h" ; then
_x11_headers="yes"
So, in other words, it:
1/ Parses the --extra-cflags option, and finds the -I options in there.
2/ Looks in /usr/include
Since $(STAGING_DIR)/usr/include is in the compiler built-in search path
for headers, we currently don't explicitly pass it in --extra-cflags, so
mplayer only looks in /usr/include. If you have X11 headers there thanks
to being installed on your build machine, everything works fine (the
rest of the build logic really uses the headers and libraries of the
cross-compiler). But if you don't have X11 headers in /usr/include, the
configure scripts assumes X11 is not available.
Since fixing the hand-written configure script of mplayer, hosted in a
Subversion repository, is beyond sanity, we simply work around this
problem by passing the appropriate -I$(STAGING_DIR)/usr/include option
in --extra-cflags.
Before this patch, during the configure script:
Checking for X11 headers presence ... no (check if the dev(el) packages are installed)
Checking for X11 ... no (check if the dev(el) packages are installed)
And then, the mplayer binary:
0x00000001 (NEEDED) Shared library: [librt.so.0]
0x00000001 (NEEDED) Shared library: [libz.so.1]
0x00000001 (NEEDED) Shared library: [libpthread.so.0]
0x00000001 (NEEDED) Shared library: [libdl.so.0]
0x00000001 (NEEDED) Shared library: [libm.so.0]
0x00000001 (NEEDED) Shared library: [libc.so.0]
With this patch, during the configure script:
Checking for X11 headers presence ... yes
Checking for X11 ... yes
And then, the mplayer binary:
0x00000001 (NEEDED) Shared library: [librt.so.0]
0x00000001 (NEEDED) Shared library: [libz.so.1]
0x00000001 (NEEDED) Shared library: [libpthread.so.0]
0x00000001 (NEEDED) Shared library: [libdl.so.0]
0x00000001 (NEEDED) Shared library: [libm.so.0]
0x00000001 (NEEDED) Shared library: [libXext.so.6]
0x00000001 (NEEDED) Shared library: [libX11.so.6]
0x00000001 (NEEDED) Shared library: [libXinerama.so.1]
0x00000001 (NEEDED) Shared library: [libXxf86vm.so.1]
0x00000001 (NEEDED) Shared library: [libc.so.0]
Fixes bug #8206
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The current BR2_GCC_ENABLE_TLS can cause users to make incorrect
choices, and is not very useful. This options allows to decide whether
we pass --enable-tls or --disable-tls to gcc, to enable or disable
support for Thread Local Storage.
Its behavior is:
- The option is default to "y" but only exists if we're using
uClibc/NPTL or glibc.
- When we're using uClibc, the option can be disabled.
So, in practice, this means that currently:
- TLS support is always on for glibc
- TLS support is on by default for uClibc/NPTL, but can be disabled in
the configuration. This is in fact bad and causes the build failure
reported in bug #7424 (this bug is still reproducible on master)
- TLS support is always disabled for uClibc/no-thread and
uClibc/linuxthreads.
- TLS support is always disabled for musl. This does not cause any
build failure, but musl can use TLS support, and therefore be more
efficient. According to
http://www.openwall.com/lists/musl/2012/10/04/1, "Note that if you've
been building gcc with --disable-tls, __thread was already working
but gets emulated (very poorly; it's slow and will abort() if it runs
out of memory) through libgcc.".
So, this commit completely removes the BR2_GCC_ENABLE_TLS and instead
makes the right choice inside gcc.mk directly:
- TLS support enabled for glibc, musl and uClibc/NPTL
- TLS support in other cases, i.e uClibc/no-thread and
uClibc/linuxthreads.
We have intentionally *not* added the option to
Config.in.legacy. Indeed, the new behavior is *exactly* the same as the
older behavior, with the exception of:
- People can no longer disable TLS support in uClibc/NPTL, which was
anyway causing a build failure and therefore was not used.
- TLS support is now enabled on musl, but people using musl already had
BR2_GCC_ENABLE_TLS not set, so they wouldn't get the legacy warning.
Fixes bug #7424.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Back in 2005, in commit
a2c326396a ("update valgrind to the latest
and greatest"), an explicit --disable-tls option was added. More
recently, in commit 31a3f4bd54 ("valgrind:
enable tls support") changed this to be conditional on
BR2_GCC_ENABLE_TLS.
However, the configure script of valgrind is perfectly capable of
detecting TLS support, even in a cross-compilation case: it tries to
compile a program that uses __thread and sees if it works.
Since we're about to modify how BR2_GCC_ENABLE_TLS is handled, we'd
better remove its usage from packages, and valgrind is the only package
using this config option.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
As described at:
4520524ba0
this commit continues a series of updates of ARC tools.
This time we're updating tools to arc-2016.09-eng010.
This engenering build contains different fixes done to TLS and
PIE features. Appropriate custom patches are removed as they have
been added to eng010.
We still keep GDB as it is of arc-2016.03 release because there're some
issues we'd like to resolve before releasing it to wider audience.
So again note this is next engineering builds of arc-2016.09 series
and it might have all kinds of breakages, please don't use it for
production builds.
Signed-off-by: Vlad Zakharov <vzakhar@synopsys.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The recent U-Boot adopts Kconfig for its configuration system.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Matt Weber <matthew.weber@rockwellcollins.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This commit adds a simple patch to the libaio build system that allows
it to be used on static-only configurations. It is probably easier to
fix this than to propagate the !BR2_STATIC_LIBS dependency.
Fixes:
http://autobuild.buildroot.net/results/8c86402bd14a0af1b82e6e07c06531a856dd37c6/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Romain Naour <romain.naour@gmail.com>
Tested-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
GMane is dead (at least its web interface), so it's no longer really
useful to reference it.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
After fixing the usual sys/cdefs.h and _P stuff the build still fails
because Openswan makes use of GLOB_ functions
/home/bernd/buildroot/br4/output/build/openswan-2.6.48/lib/libipsecconf/parser.l:200:29: error: ‘GLOB_BRACE’ undeclared (first use in this function)
globresult = glob(try, GLOB_BRACE, NULL, &globbuf);
^
/home/bernd/buildroot/br4/output/build/openswan-2.6.48/lib/libipsecconf/parser.l:200:29: note: each undeclared identifier is reported only once for each function it appears in
/home/bernd/buildroot/br4/output/build/openswan-2.6.48/lib/libipsecconf/parser.l:207:41: error: ‘GLOB_NOMAGIC’ undeclared (first use in this function)
globresult = glob(try, GLOB_BRACE|GLOB_NOMAGIC, NULL, &globbuf);
https://github.com/xelerance/Openswan/blob/master/lib/libipsecconf/parser.l#L200https://github.com/xelerance/Openswan/blob/master/lib/libipsecconf/parser.l#L207
[...]
^
which musl does not support:
http://www.openwall.com/lists/musl/2013/09/16/1
Fixes
http://autobuild.buildroot.net/results/70d/70da34c1528b51e92e9e60788f83733d70b33353/
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fixes:
http://autobuild.buildroot.net/results/928be69f90476e6b04be3a1afd3b74112bcac0a0
As mentioned in sha2/README, by default, tinydtls uses u_intXX_t data types
for 8 bit, 32 bit, and 64 bit unsigned integer type definitions. To use
uintXX_t data types as defined by recent ANSI C standards and as included in
the inttypes.h header file, SHA2_USE_INTTYPES_H has to be define at compile
time.
[Peter: reword/simplify]
Signed-off-by: Fabrice Fontaine <fabrice.fontaine@orange.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
When compiling with a toolchain targetted at ucLinux, libserialport's
configure.ac would fail at detecting the target operating system.
As a result, the Linux-specific files were not compiled in that
particular case.
While this commit does not fix any autobuider failure for this package,
it fixes autobuilder failures for other packages, for instance:
http://autobuild.buildroot.net/results/69e/69e43bc171e554cf10f2ad526cebf5e0e524538a/
Signed-off-by: Paul Cercueil <paul.cercueil@analog.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Currently, we forcibly tell neon's configure where to look for libexpat.
This means that neon does not search for it, and consequently forgets to
add -lexpat as its Libs.Private in its .pc file. As thus, a static link
against neon forgets to pull in -lexpat (it works for a dynamic link
because libneon has a NEEDED on libexpat).
The reason for specifying the explicit path in this case is lost to
history; neon's configure can correctly find libexpat nowadays.
Fixes:
http://autobuild.buildroot.org/results/884/884746351fc47f4ad19fb3fda7c5e0ee85fcff15/http://autobuild.buildroot.org/results/0c5/0c584522c26640e29980150a87a5b5d8c02e5f8b/
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
