To be consistent with the recent change of FOO_MAKE_OPT into FOO_MAKE_OPTS,
make the same change for FOO_CONF_OPT.
Sed command used:
find * -type f | xargs sed -i 's#_CONF_OPT\>#&S#g'
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This fixes the following linux kernel build errors:
LD init/built-in.o
net/built-in.o: In function `raw_proc_exit':
(.init.text+0xe29): dangerous relocation:
call8: call target out of range: udp_proc_register
net/built-in.o: In function `udp_table_init':
(.init.text+0xf09): dangerous relocation:
call8: call target out of range: udp_proc_register
net/built-in.o: In function `inet_init':
af_inet.c:(.init.text+0x142e): dangerous relocation:
call8: call target out of range: udp4_proc_exit
net/built-in.o: In function `ip_auto_config':
ipconfig.c:(.init.text+0x28aa): dangerous relocation:
call8: call target out of range: arp_send
Backported from: 331ed1307b93d3ff77d248bdf2f7b79a20851457
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
You get following linking error, when trying to build a
toolchain for bfin with newer binutils:
bfin-buildroot-linux-uclibc/bin/ld: fde encoding in _divdi3_s.o(.eh_frame) prevents .eh_frame_hdr table being created.
Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Now when new shiny tools are released by Synopsys we're ready for version
update in Buildroot.
Important change in this release is switching to combined "binutils-gdb" repo
in accordance to upstream move.
Following patch now is a part of the most recent relese:
e6ab8cac62
So dropping it.
package/binutils/arc-4.8-R3/0001-arc-Honor-DESTDIR-in-custom-Makefile.patch
Since arc-2014.08 tools are still based on GCC 4.8 following patch is still
relevant so moving to the new folder to matxh ARC gcc bump.
package/gcc/arc-4.8-R3/100-libstdcxx-uclibc-c99.patch ->
package/gcc/arc-2014.08/100-libstdcxx-uclibc-c99.patch
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Cc: Anton Kolesov <akolesov@synopsys.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
If Binutils and/or GDB are fetched from the unified binutils-gdb
repository, then the tarball will contain both Binutils and GDB
sources, unlike the "normal" tarballs that contain only the titular
package. To keep packages separated in Buildroot we need to disable
undesired components when configuring.
Binutils and GDB migrated to a common Git repository in the October
2013 [1]. Previous Git repositories were incomplete copies of CVS
repository which copied only the relevant files (no binutils files in
GDB, and vice versa). In the new binutils-gdb repository there is no
such separation and a result all files exist in directory after
checkout. So if "configure" and "make" are used without explicit
targets, all projects will be built: binutils, ld, gas, bfd, opcodes,
gdb, etc. In case of Buildroot this would mean that selecting Binutils
only, still will build both Binutils and GDB. And if GDB is selected
as well, then both packages will be built two times, and Binutils from
GDB directory will overwrite initial build of Binutils (or vice versa
if Binutils will be built after the GDB). This is a serious problem,
because binutils and GDB use separate branches in this common
repository. In case of Buildroot this means that separate Git commits
(or tags) should be used when downloading source from Git.
This affects only Git repositories, because GNU release tarballs still
contain only relevant packages.
This change is backward compatible, because if "normal" tarball is
used (without extra directories), than --disable-* configure options
are just ignored by configure.
[1] https://sourceware.org/ml/gdb/2013-10/msg00071.html
[Thomas: use variables to factorize options, and add comments in the
relevant .mk files to explain what's going on.]
Signed-off-by: Anton Kolesov <Anton.Kolesov@synopsys.com>
Cc: Alexey Brodkin <abrodkin@synopsys.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
After the following commits:
26974bf6a7 use default binutils for sh architecture
6f1cf344d9 binutils: Use the default version by default on MIPS
the 2.21.1 binutils version is no longer required, and since it's an
old version, we get rid of it.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Following d4839ffcab ("binutils: remove
2.20.1, 2.21 and 2.23.1"), Config.in.host contains unneeded
definitions of BR2_BINUTILS_VERSION for no longer existing
versions. This patch fixes that.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This fixes the following build error reproducible with any linux kernel
module built with a recent buildroot toolchain:
LD [M] fs/jbd2/jbd2.ko
/bin/sh: line 1: 12069 Segmentation fault
buildroot/host/usr/bin/xtensa-buildroot-linux-uclibc-ld -r --no-relax
-T linux/scripts/module-common.lds --build-id
-o fs/jbd2/jbd2.ko fs/jbd2/jbd2.o fs/jbd2/jbd2.mod.o
Backported from: e7d17e71cdc10a2e81e454ce3b9637f1b2a587f2
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
- The 2.20.x series is old, it no longer makes sense to support it.
- In the 2.21.x series, we still have 2.21.1, so keeping 2.21 doesn't
make much sense, so this patch removes it.
- Similarly for the 2.23.x series, having both 2.23.1 and 2.23.2
doesn't make much sense, so this patch removes 2.23.1 and keeps
2.23.2.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Tested toolchain compiles with binutils 2.22 and 2.24.
Result tested in Qemu 2.0.0. (only little endian version
tested)
Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
makeinfo is known to cause problems when building old texi files with more
recent host makeinfo.
In particular binutils-2.18 won't build on Fedora 20 without this change.
Even though more up to date binutils does build without this change there's
no guaranty it will with bump of host makeinfo in the future.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Cc: Anton Kolesov <akolesov@synopsys.com>
Cc: Peter Korsgaard <peter@korsgaard.com>
Cc: Gustavo Zacarias <gustavo@zacarias.com.ar>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
ARC-specific Makefile has been ignoring DESTDIR when doing target "install".
This has been causing build failure for native binutils, since it was trying
to install into the host's "/usr". This commit adds a patch that teaches
Makefile to honor DESTDIR. This patch should be removed after ARC Binutils
will be bumped to next release.
This fixes:
http://autobuild.buildroot.net/results/68ee094509db3e8fbedf9bab5745ff68cdfe0a84/
Signed-off-by: Anton Kolesov <Anton.Kolesov@synopsys.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This patch adds support for powerpc64le-linux-gnu. This includes
needed patches to fakeroot and gmp.
gmp patch is from upstream HG tree.
fakeroot patch is from Ubuntu written by Adam Conrad.
Signed-off-by: Jeff Bailey <jeffbailey@google.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The autobuilders are not able to build glibc on AArch64 since we moved
to the internal toolchain backend as the default for AArch64. The
reason is that the cross-ld segfaults while linking of the glibc
utilities. Unfortunately, the issue has so far been impossible to
reproduce outside of the autobuilder CI loop itself: even on the same
machine, in the same chroot, the issue does not appear.
Today, Will Newton helped me analyze a bit further the problem. In the
logs of the build machine, we have found that the following segfault
notification matched the dates of the autobuilder failures:
/var/log/syslog:May 15 10:39:20 sd-56966 kernel: [767023.832598] ld[6846]: segfault at 1b2c002 ip 00000000004caf80 sp 00007fffaa308df8 error 4 in ld[400000+1b9000]
/var/log/syslog.2.gz:May 13 07:58:24 sd-56966 kernel: [585094.434264] ld[17761]: segfault at 154b002 ip 00000000004caf80 sp 00007fff0d400168 error 4 in ld[400000+1b9000]
/var/log/syslog.3.gz:May 12 20:24:08 sd-56966 kernel: [543558.227915] ld[14841]: segfault at 2706002 ip 00000000004caf80 sp 00007fffc08d41c8 error 4 in ld[400000+1b9000]
/var/log/syslog.4.gz:May 11 19:51:59 sd-56966 kernel: [455484.523033] ld[50162]: segfault at 1f00002 ip 00000000004caf80 sp 00007fff14a02328 error 4 in ld[400000+1b9000]
/var/log/syslog.4.gz:May 12 05:13:37 sd-56966 kernel: [489085.120089] ld[32067]: segfault at 2430002 ip 00000000004caf80 sp 00007fffc448db48 error 4 in ld[400000+1b9000]
/var/log/syslog.6.gz:May 9 15:20:38 sd-56966 kernel: [266948.197141] ld[13483]: segfault at ff0002 ip 00000000004caf80 sp 00007fff7e4fe948 error 4 in ld[400000+1b9000]
/var/log/syslog.7.gz:May 8 16:45:08 sd-56966 kernel: [185853.688607] ld[1757]: segfault at 20b1002 ip 00000000004caf80 sp 00007fffd07d5ae8 error 4 in ld[400000+1b9000]
See
http://autobuild.buildroot.org/?reason=glibc-2.18-svnr23787&arch=aarch64
for the autobuilder results.
So, the segfault always happens while accessing an address 2 bytes
after the beginning of a page: it looks like a buffer overflow, which
gets triggered because the object is placed towards the end of the
previous page, and crosses over the next, unallocated page.
Moreover, we looked at the 0x4caf80 address in an AArch64 cross-ld
built by Buildroot, and it turns out that it is part of the
iterative_hash() function. This nicely correlates with the patch that
Will Newton had pointed in
http://lists.busybox.net/pipermail/buildroot/2014-May/095881.html as a
fix for invalid memory accesses reported by Valgrind in the AArch64
cross-ld, specifically around the same area of 'ld'.
Therefore, even though we have not been able to reproduce the issue
outside of the autobuilders, and cannot confirm that the patch is
fixing the issue, I propose to integrate this binutils patch into
Buildroot. It is anyway an upstream binutils patch, which fixes a real
problem.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This fixes the following build error often seen during linux kernel
linking step with relaxation enabled:
dangerous relocation: call8: misaligned call target: (.text.unlikely+0x63)
Backported from: a35d5e823fdfe8a6e7e05ca8e3fb8bb5697335b1
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Upstream binutils 2.24 works fine for microblaze, no need for
Xilinx Git.
[Peter: disable older versions as suggested by Gustavo]
Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
Acked-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Tested-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Rebuilding as.info with makeinfo version 5.2 results in a build error,
even with pristine binutils source. Dropping hunks that change *.texi*
files avoids documentation rebuild.
Reported-by: Vincent Stehlé <vincent.stehle@freescale.com>
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This fixes compilation of huge source files that have jumps with offsets
greater than 128 Kbytes, that otherwise fails with such messages:
{standard input}:65267: Error: operand 1 of 'j' has out of range value '131089'
{standard input}:106879: Error: operand 1 of 'j' has out of range value '4294833951'
Fixes:
http://autobuild.buildroot.net/results/e45/e450d5efc7435035c956bb962d598837648f319d/
Backported from: a82c7d9030b67a6a76a5403d0e1641f9e42141ac
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Fixes http://autobuild.buildroot.org/results/1ea/1ea98985ce06dc1b7569ef5abe2fc13090fb5f3a
The upstream patch patches both configure.ac and configure, so we keep
that.
It is numbered 001 because it is an upstream patch, so it should come
before the buildroot patches.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Some packages (actually, just oprofile) need to link against libiberty.
This option just installs libiberty.a so it has no effect on the target,
therefore it's not needed to add a config option for it.
Before binutils-2.24, there was a bug in libiberty/Makefile.in that
caused libiberty to be installed regardless of the
--enable-install-libiberty option. This problem wasn't noticed before
because binutils-2.24 is not selected on any of the autobuilders: the
version can only be selected if an internal toolchain is used, and it
defaults to 2.21.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
In the Config.in file of package foo, it often happens that there are other
symbols besides BR2_PACKAGE_FOO. Typically, these symbols only make sense
when foo itself is enabled. There are two ways to express this: with
depends on BR2_PACKAGE_FOO
in each extra symbol, or with
if BR2_PACKAGE_FOO
...
endif
around the entire set of extra symbols.
The if/endif approach avoids the repetition of 'depends on' statements on
multiple symbols, so this is clearly preferred. But even when there is only
one extra symbol, if/endif is a more logical choice:
- it is future-proof for when extra symbols are added
- it allows to have just one strategy instead of two (less confusion)
This patch modifies the Config.in files accordingly.
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
When the binutils source code is pulled from a Git repository, a
number of generated files are not present, and need to be
re-generated. Those files are generated by flex, bison, and texinfo,
so we need to pull the corresponding dependencies.
Notice that we tried avoiding the texinfo dependency by doing a number
of MAKEINFO tricks, but none of them worked properly, so we've instead
chosen to depend on host-texinfo.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
pkg-autotools.mk already handles static/shared linking, so no need to
explictly force it. Worse even, the build fails with BR2_PREFER_STATIC_LINK
as we end up calling libtool with --static when it tries to link the .so,
breaking the build:
../ld: attempted static link of dynamic object
`../opcodes/.libs/libopcodes.so'
collect2: error: ld returned 1 exit status
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2.21.1 is getting quite old, the linker issues with 2.22 seems to be
(mostly?) sorted out by now and armhf needs 2.22+, so let's bump the
default version.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The ARM EABIhf support was introduced in Binutils 2.22, so earlier
versions should not be selected when EABIhf is used.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
When a Xtensa specific patch needs to be applied, it should be applied
both when doing the target and the host build.
This change is part of the effort to remove the differences between
host and target post-extract and post-patch hooks, that are
problematic for the out-of-tree support.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
On commit 5538e47662 the versioned package
patches changed the directory structure but the packages weren't fixed.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Except for architecture and processor names, buildroot uses capitalized
configuration names, so change the macro names for xtensa to follow that
standard.
Change the overlay file to have a subdirectory for each component
(gdb, binutils, gcc, etc.) to make it more future-prove.
Signed-off-by: Chris Zankel <chris@zankel.net>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Xtensa is a configurable processor architecture, which allows to define
additional instructions and registers. The required variant specific
information for the toolchain is delivered in an 'overlay' file, which
needs to be 'untarred' to the corresponding directories after the
source is installed and patched.
This patch provides support for binutils, gcc, and gdb with a very
limited changes to the build scripts. These additions are only executed
for the Xtensa architecture and have no effect on other architectures.
[Thomas: rebased on top of the 'arch: improve definition of gcc mtune,
mcpu, etc.' patch, and changed 'Target ABI' to 'Target Architecture
Variant'].
Signed-off-by: Chris Zankel <chris@zankel.net>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
