GDB has been updated to 8.0 version in the release.
https://releases.linaro.org/components/toolchain/binaries/6.4-2017.08
Tested with qemu_aarch64_virt_defconfig.
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
GDB has been updated to 8.0 version in the release.
https://releases.linaro.org/components/toolchain/binaries/6.4-2017.08
Tested with qemu_arm_vexpress_defconfig.
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Since 392b0a26f5 (toolchain-external: default BR2_TOOLCHAIN_EXTERNAL_PATH
to empty), calling 'make clean' or similar can yield a spurious stderr
message:
dirname: missing operand
Try 'dirname --help' for more information.
Which is definitely baffling and unsettling...
It turns out that it is pretty trivial to reproduce, and this defconfig
is just enough:
$ cat my-defconfig
BR2_TOOLCHAIN_EXTERNAL=y
$ make BR2_DEFCONFIG=$(pwd)/my-defconfig defconfig
$ make clean
dirname: missing operand
Try 'dirname --help' for more information.
[--snip--]
This is because the cross-compiler is not found in the PATH (and for
good reasons, I don't have it in the PATH, not even at all).
So, when the cross-compiler is not found in the path, we simply
continue as if all was good, and postpone the check to much later,
when we try to copy the toolchain libs...
So, use a make construct rather than calling to the shell: $(dir ...)
does not whine if passed nothing.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Arnout Vandecappelle <arnout@mind.be>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Thomas De Schampheleire <patrickdepinguin@gmail.com>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The big.LITTLE configurations can be optimised for by gcc, and a few
users wonder what they should choose when they have such CPUs.
Add new entries for those big.LITTLE configurations.
Note: the various combos were added in various gcc versions, but only
really worked in later versions:
Variant | Introduced in | First built in
----------+---------------+----------------
a15-a7 | 4.9 | 4.9
a17-a7 | 5 | 5
a57-a53 | 4.9 | 6
a72-a53 | 5 | 6
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Thomas De Schampheleire <patrickdepinguin@gmail.com>
Cc: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
-mnan option was added in gcc-4.9.0 so make sure that users cannot
select the NaN mode when using toolchains that have a gcc older
than 4.9.0, and also make sure that the -mnan option is not passed at
all to the toolchain-wrapper and target cflags.
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
MIPS32 support different FP modes (32,xx,64), so give the user the
opportunity to choose between them. That will cause host-gcc to be built
using the --with-fp-32=[32|xx|64] configure option. Also the
-mfp[32|xx|64] gcc option will be added to TARGET_CFLAGS and to the
toolchain wrapper.
FP mode option shouldn't be used for soft-float, so we add logic in the
toolchain wrapper if -msoft-float is among the arguments in order to not
append the -fp[[32|xx|64] option, otherwise the compilation may fail.
Information about FP modes here:
- https://sourceware.org/binutils/docs/as/MIPS-Options.html
- https://dmz-portal.imgtec.com/wiki/MIPS_O32_ABI_-_FR0_and_FR1_Interlinking#5._Generating_modeless_code
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
MIPS supports two different NaN encodings, legacy and 2008. Information
about MIPS NaN encodings can be found here:
https://sourceware.org/binutils/docs/as/MIPS-NaN-Encodings.html
NaN legacy is the only option available for R2 cores and older.
NaN 2008 is the only option available for R6 cores.
R5 cores can have either NaN legacy or NaN 2008, depending on the
implementation. So, if the user selects a generic R5 target architecture
variant, we show a choice menu with both options available. For well
known R5 cores we directly select the NaN enconding they use.
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
It makes no sense to default to an arbitrary path. In addition, it in
fact works correctly when it is empty. In that case, the toolchain will
be searched in PATH.
Update the help text to explain the above, and also that the compiler
is supposed to be in the bin subdirectory.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Commit 32bec8ee2f (toolchain-external: copy ld*.so* for all C libraries)
removed the definition of TOOLCHAIN_EXTERNAL_MUSL_LD_LINK. Remove also the
reference to it.
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Since things are no longer installed in $(HOST_DIR)/usr, the callers
should also not refer to it.
This is a mechanical change with
git grep -l '$(HOST_DIR)/usr/bin' | xargs sed -i 's%$(HOST_DIR)/usr/bin%$(HOST_DIR)/bin%g'
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
libgcc_s.so is now added to TOOLCHAIN_EXTERNAL_LIBS for glibc/uclibc
in one place, and for musl in another place. Bottom line: it should be
in TOOLCHAIN_EXTERNAL_LIBS unconditionally.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Currently, for the dynamic loader, we're copying ld*.so* for glibc and
uClibc, except for glibc/EABIhf where we are explicitly copying
ld-linux-armhf.so.*. For musl, we're not copying the dynamic linker
because it's simply a symbolic link to libc.so. However, the name of
the musl dynamic linker changes from one architecture to the other,
and we don't handle all cases.
Since handling the musl dynamic linker symlink creation is becoming
more and more annoying to maintain, this commit makes musl use the
same mechanism as glibc/uClibc: put the dynamic linker in
TOOLCHAIN_EXTERNAL_LIBS.
In addition, the special condition on glibc/EABIhf was added in
11ec38b695 ("toolchain-external: fix
Linaro ARM toolchain support") because an old Linaro toolchain had two
dynamic loaders, and we wanted to copy only one. But 1/ this is old
and 2/ having the two dynamic linkers doesn't really matter.
So this commit simply unconditionally adds "ld*.so*" to
TOOLCHAIN_EXTERNAL_LIBS, regardless of the C library being chosen. It
re-uses the musl dynamic linker symlink from the sysroot, which makes
it always correct, and allows us to remove the
TOOLCHAIN_EXTERNAL_MUSL_LD_LINK hook, and all the related logic.
This commit therefore solves two problems with the musl dynamic linker
symbolic link creation logic:
1 We support all architectures, without having to hardcode in
Buildroot the mapping between the CPU architecture and the
corresponding dynamic linker name. For example, our current logic
was not handling the mips64+n32 ABI case, where the dynamic linker
is named ld-musl-mipsn32el.so.1.
2 We support Crosstool-NG musl toolchains, where the dynamic linker
is in /lib, but libc.so is in /usr/lib.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
This commit therefore replaces:
- https://patchwork.ozlabs.org/patch/780411/ (was another solution
for solving problem 1 above)
- https://patchwork.ozlabs.org/patch/763977/ and
https://patchwork.ozlabs.org/patch/748974/ (was another solution
for solving problem 2 above)
We currently use $(HOST_DIR)/usr as the prefix for host packages. That
has a few disadvantages:
- There are some things installed in $(HOST_DIR)/etc and
$(HOST_DIR)/sbin, which is inconsistent.
- To pack a buildroot-built toolchain into a tarball for use as an
external toolchain, you have to pack output/host/usr instead of the
more obvious output/host.
- Because of the above, the internal toolchain wrapper breaks which
forces us to work around it (call the actual toolchain executable
directly). This is OK for us, but when used in another build system,
that's a problem.
- Paths are four characters longer.
To allow us to gradually eliminate $(HOST_DIR)/usr while building
packages, replace it with a symlink to .
The symlinks from $(HOST_DIR)/usr/$(GNU_TARGET_NAME) and
$(HOST_DIR)/usr/lib that were added previously are removed again.
Note that the symlink creation will break when $(HOST_DIR)/usr
already exists as a directory, i.e. when rebuilding in an existing
output directory. This is necessary: if we don't break it now, the
following commits (which remove the usr part from various variables)
_will_ break it.
At the same time as creating this symlink, we have to update the
external toolchain wrapper and the external toolchain symlinks to go
one directory less up. Indeed, $(HOST_DIR) is one level less up than
it was before.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Reviewed-by: Romain Naour <romain.naour@smile.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Static build with external musl toolchain leaves a dangling symlink to
libc.so. Don't create that symlink on static build.
Cc: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Remove mention of toolchains the we don't have.
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Since glibc 2.17, executable link command need not include the -lrt option for
clock_* system calls. As a result, over time less and less software packages
bother to check whether to toolchain needs -lrt. We are now at a point where
maintainers refuse to add this complexity into their build system. This
requires Buildroot to carry patches fixing this issue indefinitely.
glibc 2.17 is now 4.5 years old. There is no reason to use an older version
with current software.
This commit removes the predefined profile for CodeSourcery sh toolchain that
is based on glibc 2.16. One may still use the custom external toolchain
support in Buildroot to get this toolchain back, and deal with any build
issues that this toolchain causes.
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Since glibc 2.17, executable link command need not include the -lrt option for
clock_* system calls. As a result, over time less and less software packages
bother to check whether to toolchain needs -lrt. We are now at a point where
maintainers refuse to add this complexity into their build system. This
requires Buildroot to carry patches fixing this issue indefinitely.
glibc 2.17 is now 4.5 years old. There is no reason to use an older version
with current software.
This commit removes the predefined profile for CodeSourcery x86 toolchain that
is based on glibc 2.16. One may still use the custom external toolchain
support in Buildroot to get this toolchain back, and deal with any build
issues that this toolchain causes.
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The external toolchain code has some logic to calculate the correct name
for the dynamic linker symbolic link that needs to be created when the
musl C library is being used. There was already some handling for the
mipsel+soft-float case, but not for the mips+soft-float case. Due to
this, the symbolic link was incorrectly named, and programs were
referencing an non-existing file.
Reported-by: Florent Jacquet <florent.jacquet@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Remove upstream patches:
831-ARM-PR-target-70473-Reduce-size-of-Cortex-A8-automat.patch
870-xtensa-Fix-PR-target-78118.patch
871-xtensa-Fix-PR-target-78603.patch
890-fix-m68k-compile.patch:
1701058da9
892-libgcc-mkmap-symver-support-skip_underscore.patch:
6c8f362e1f
893-libgcc-config-bfin-use-the-generic-linker-version-in.patch:
966d046c08
894-libgcc-fix-DWARF-compilation-with-FDPIC-targets.patch:
397d0e43ab
895-bfin-define-REENTRANT.patch:
da89a4dcdf
940-uclinux-enable-threads.patch:
b9ce54109e
941-mips-Add-support-for-mips-r6-musl.patch:
8371706509
Remove obsolete patches:
301-missing-execinfo_h.patch: boehm-gc removed from gcc sources:
baf7122876
830-arm_unbreak_armv4t.patch: SUBTARGET_CPU_DEFAULT removed:
ff3caa3ade
Add a new patch to allow to build gcc 7.1 without extracting gcc/testsuite
directory.
This new gcc version require a kernel patch [1] to avoid a build issue with
____ilog2_NaN symbol. The following kernel version contain contain already
this patch :
4.11, 4.10.6, 4.9.18, 4.4.57, 3.18.50 and 3.12.73.
To build a toolchain based on gcc 7 and uClibc-ng 1.0.24, the patch [2] is
required to avoid a build issue due to missing aligned_alloc() definition.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=474c90156c8dcc2fa815e6716cc9394d7930cb9c
[2] https://cgit.openadk.org/cgi/cgit/uclibc-ng.git/commit/?id=5b0f49037e8ea8500b05c8f31ee88529ccac4cee
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Tested-by: Theodore Ateba <tf.ateba@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Waldemar Brodkorb <wbx@openadk.org>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
An autobuilder exception has been added to avoid testing qt gui module
with the CodeSourcery NiosII toolchain. This allow to remove the
BR2_TOOLCHAIN_HAS_BINUTILS_BUG_19405 symbol.
This reverts commit 5dce3c05b5.
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The current URL returns error 403: Forbidden, so switch to https.
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The current URL returns error 403: Forbidden, so switch to https.
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The current URL returns error 403: Forbidden, so switch to https.
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Tested with qemu_nios2_10m50_defconfig and Qemu 2.9.0 release.
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The current URL returns error 403: Forbidden, so switch to https.
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The input to copy_toolchain_lib_root is not one library, not a list of
libraries, but a library name pattern with glob wildcards.
This pattern is then passed to 'find' to get the actual list of libraries
matching the pattern. Reflect this using an appropriate variable name.
Note: if the root of the buildroot tree contains a file matching one of
these library patterns, the copying of libraries from staging to target will
not be correct. It is not impossible to fix that, e.g. using 'set -f', but
maybe it's not worth it.
Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The toolchain from the Cavium Octeon SDK has a sysroot layout as follows:
./lib32
./lib32/octeon2
./lib32-fp
./lib64
./lib64/octeon2
./lib64-fp
./usr
./usr/lib
./usr/lib32
./usr/lib32/octeon2
./usr/lib32-fp
./usr/lib64
./usr/lib64/octeon2
./usr/lib64-fp
./usr/bin
./usr/bin32
./usr/bin32-fp
./usr/bin64-fp
./usr/libexec
./usr/libexec32
./usr/libexec32-fp
./usr/libexec64-fp
./usr/sbin
./usr/sbin32
./usr/sbin32-fp
./usr/sbin64-fp
./usr/include
./usr/share
./sbin
./sbin32
./sbin32-fp
./sbin64-fp
./etc
./var
with the following selections:
- lib64 : default
- lib64/octeon2 : -march=octeon2
- lib64-fp : -march=octeon3
- lib32 : -mabi=n32
- lib32/octeon2 : -mabi=n32 -march=octeon2
- lib32-fp : -mabi=n32 -march=octeon3
In case of '-mabi=n32 -march=octeon2' (but same is true for n64+octeon2)the
original Buildroot toolchain logic would copy both the libraries in
lib32 as the subdirectory lib32/octeon2, which means that every library is
installed twice (but only one of each is really needed).
While ARCH_LIB_DIR is determined by the location of libc.a, which in this
case is effectively:
<sysroot>/usr/lib32/octeon2/libc.a
the variable only retains 'lib32' and not 'lib32/octeon2' as expected.
To make Buildroot cope with this style of toolchain layout, we need to adapt
the calculation of ARCH_LIB_DIR to also include the second part.
This, in turn, means that ARCH_LIB_DIR is no longer guaranteed to be a
singular path component, resulting in some additional changes.
Certain older Linaro toolchains actually had the same layout. Libraries were
located in lib/<tuple> rather than lib directly. Previously, this was
handled by adding a toolchain-specific fixup that creates a symlink
lib/<tuple> -> lib, but with this patch this would no longer be needed.
Note that one difference with the Octeon case is that these Linaro
toolchains are not actually multilib, i.e. there is just one location with
the libraries and thus there is no problem with duplicated libraries.
Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Normally, the Buildroot toolchain logic copies all required libraries from
the external toolchain to the staging directory, including the dynamic
loader ld-*.so.
There are cases, however, where the dynamic loader is _not_ automatically
copied to staging. This happens when the dynamic loader is not inside
ARCH_LIB_DIR itself (e.g. lib64), but instead resides in 'lib' (assume, of
course, that ARCH_LIB_DIR != 'lib').
Currently, this is fixed in a toolchain-specific fixup, e.g. by recreating a
missing symlink or copying over a missing file. Such toolchain specific
fixups are not very nice.
Moreover, in a subsequent patch, the value of ARCH_LIB_DIR changes for some
toolchains, causing them to have the same problem of a missing dynamic
loader. This used to be the case for older Linaro toolchains with libraries
in 'lib/<tuple>': Buildroot used to set ARCH_LIB_DIR=lib but the mentioned
patch changes it to 'lib/<tuple>' instead. As a result, the files directly
under 'lib/' will no longer be copied. There should be none, but the dynamic
loader is a notable exception.
[Note: support for these older Linaro toolchain has been removed in 2016.11]
Instead, copy over the ld.so file(s)/link(s) from the extracted toolchain
into staging, in the central copy_toolchain_sysroot function. The existing
toolchain logic will then handle the copy of these files from staging to
target.
This means the toolchain-specific fixups can be removed.
Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The check_arm_abi function takes as second argument the path to the
cross-readelf, but does not use it. Therefore, this commit gets rid of
this unnecessary argument.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The current test to verify if the toolchain uses musl or not is based on
checking if /lib/libc.so or /lib/libm.so exist in the sysroot. However,
some toolchains (notably Crosstool-NG ones) put these libraries in
/usr/lib/.
To fix this, build a minimal C program and check if the program
interpreter contains /lib/ld-musl.
Signed-off-by: Ilya Kuzmich <ilya.kuzmich@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
TOOLCHAIN_EXTERNAL_READELF is defined to
$(TOOLCHAIN_EXTERNAL_CROSS)readelf$(TOOLCHAIN_EXTERNAL_SUFFIX), where
TOOLCHAIN_EXTERNAL_SUFFIX is .br_real for Buildroot
toolchains. However, this is bogus, because readelf is not wrapped by
the Buildroot toolchain wrapper, so "<arch>-readelf.br_real" never
exists.
Therefore, it should simply be defined as
$(TOOLCHAIN_EXTERNAL_CROSS)readelf. Currently,
TOOLCHAIN_EXTERNAL_READELF is not used anywhere, so it wasn't visible,
but a follow-up commit will make use of it.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
libanl.so is needed for asynchronous network address and service
translation, declared in netdb.h
Signed-off-by: Jesper Bækdahl <jbb@gamblify.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Tested with qemu-2.7.1-2.fc25 and the qemu_aarch64_virt_defconfig
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Tested with qemu-2.7.1-2.fc25 and the qemu_arm_vexpress_defconfig
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Sync external prebuilt toolchain with the one we now build in Buildroot,
i.e. arc-2016.09. Since that prebuilt toolchain finally has IPv6 enabled
it works pretty fine for building packages in Buildroot.
Still note:
1) There might be subtle differences between uClibc configuration
compared to Buildroot's one.
2) A couple of patches we apply on top of Builroot-built toolchain
are obviously missing in the prebuilt version - they will be
available in the next release.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Cc: Vlad Zakharov <vzakhar@synopsys.com>
Cc: Peter Korsgaard <peter@korsgaard.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The variables LIBC_A_LOCATION and ARCH_LIBC_A_LOCATION were killed in commit
646bd86908 but the corresponding descriptions
were never removed.
Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Also...
- Fix a typo in Config.in
- Take into account the host's architecture to download the x86 or
x86_64 version. This makes the IA32 libs dependency in unnecessary.
[Peter: fix kernel headers comment as pointed out by Romain]
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Reviewed-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Also...
- Fix a typo in Config.in
- Take into account the host's architecture to download the x86 or
x86_64 version. This makes the IA32 libs dependency in unnecessary.
[Peter: fix kernel headers comment as pointed out by Romain]
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Reviewed-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Keep BR2_TOOLCHAIN_HAS_BINUTILS_BUG_19405 since it's not fixed in
Binutils 2.26.
Runtime tested with an experimental version of Qemu 2.7 for Nios2.
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
