[Peter: don't allow MMU on bfin]
Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
The Alpha, CRIS, IA64 and Sparc64 architectures have been marked as
deprecated during the previous release cycle. They are not widely used
in embedded systems and/or no longer supported by their manufacturers
and/or not properly supported in Buildroot.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The CRIS architecture support in Buildroot hasn't been updated since a
long time. Even a toolchain with recent kernel headers does not build
due to missing patches.
Moreover, the CRIS architecture has been discontinued by Axis, as
visible at http://www.axis.com/products/dev/index.htm. We will remove
it from Buildroot at the next release cycle.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Those architectures don't exist anymore (Alpha, IA64) or aren't widely
used for embedded systems running Linux. Moreover, no clear Buildroot
maintainer has stepped in to maintain these architectures, so it's
better to not pretend that we support them.
The goal is to mark them as deprecated in 2010.08 and remove them in
2010.11.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
This commit solves bug #1051. The problem in this bug in that WebKit
compiles a sample C program, which uses WebKit. As WebKit is written
in C++, even though the program it built with CROSS-gcc, it must be
linked with libstdc++. However, CROSS-gcc can't find the libstdc++ has
it's hidden inside <sysroot>/<tuple>/lib.
Therefore, this commit creates a symbolic link <sysroot>/<tuple>/lib
-> <sysroot>/lib before running the CROSS-gcc installation. While this
may look like a hack, this is the solution used by both Crosstool-NG
and OpenWRT.
Moreover, with this symbolic link in place, I think bug #1741 may also
be solved. The problem in this bug is that the linker tries to link
against /lib/libc.so.0. This is due to the fact that the linker finds
a libc.so script file in the original toolchain location and not
inside the copy of the toolchain sysroot in $(STAGING_DIR). As the
script file is found outside of the current toolchain sysroot, ld
considers the script has non-sysrooted, and therefore doesn't prefix
all paths found in the script file (such as /lib/libc.so.0) with the
sysroot path, leading to the failure.
So, in details, this commit :
* Adds a BR2_ARCH_IS_64 invisible config knob that is used to know if
the arch is a 64 bits architecture or not.
* Creates the <sysroot>/<tuple>/lib -> <sysroot>/lib symbolic link,
and the <sysroot>/<tuple>/lib64 -> <sysroot>/lib64 symbolic link if
needed.
* Fixes the external toolchain sysroot detection code so that the
'sed' replacement is done *after* the readlink -f evaluation.
I have tested this by building ARM, x86 and x86_64 toolchains with
Buildroot, and then use these toolchains as external toolchains to
build a full X.org/Gtk/WebKit/Midori stack. I have also done a
complete ARM Buildroot internal toolchain build with the same full
X.org/Gtk/WebKit/Midori stack.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Has been marked as broken for more than 1 year, with no indication
that anyone cares, and it needs a bunch of special handling.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Use of OABI is strongly discouraged since years now.
Signed-off-by: Bernhard Reutner-Fischer <rep.dot.nop@gmail.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Closes#367.
arm926t was wrongly listed as armv4t, and not armv5te - leading to
the following error while compiling the kernel (2.6.28):
CC arch/arm/kernel/traps.o
{standard input}: Assembler messages:
{standard input}:1094: Error: selected processor does not support `pld [r6,#0]'
Signed-off-by: Alex Dobrynin <alex_dobrynin@hotmail.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
