Age | Commit message (Collapse) | Author |
|
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
|
|
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
|
|
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
|
|
git://git.free-electrons.com/users/thomas-petazzoni/buildroot
|
|
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
|
|
Linaro has just released a new pre-built toolchain, available as a
tarball, which is a pure toolchain (only the C library is
included). This makes this new Linaro 2012.01 toolchain usable in
Buildroot, so let's integrate the support for it.
In addition to simply adding the new external toolchain at the usual
locations, this patch allows need to adapt a few things to support
Linaro toolchains. Most toolchains store their libraries in the "lib/"
or "usr/lib" directories relative to the toolchain. Buildroot
toolchains on the other hand, store the libraries in the
"usr/<target-name>/lib" directory. And the Linaro toolchain has
choosen to use the "lib/<target-name>" directory. Therefore, this
patch adjust:
* The logic to search a particular library when that library needs to
be copied to the target directory
* The logic to deduce the sysroot directory from the libc.a file
location in the toolchain: removing "(usr/?)lib(64?)" is no longer
sufficient, we need to take into account the "lib/<target-name>/"
case.
Since the Linaro toolchain generates code for Cortex-A processors
only, the selection of this toolchain is limited to Cortex-A8 and
Cortex-A9.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
|
|
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
|
|
The current check for uClibc toolchain was verifying that a
ld-uClibc.so dynamic loader was present. However, with static-only
uClibc toolchains, this does not work. Instead, we check for an
uClibc-specific header file in the sysroot.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
|
|
When the mechanism that allows Buildroot to download external
toolchains automatically was added, all the sanity checks on the
external toolchains were not performed. This commit re-enables those
checks that we already do on external toolchains that are not
downloaded/extracted by Buildroot. This makes the toolchain checks
more consistent accross various configurations.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
|
|
Each multilib variant need to be selected using a special combination
of flags, requiring specific choices of the Buildroot options. This
commit documents those configuration choices to make it easier to use
the various multilib variants.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
|
|
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
|
|
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
|
|
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
|
|
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
|
|
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
|
|
We are going to add one more ARM Sourcery toolchain version, so it's
time to remove the oldest version.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
|
|
The BR2_TARGET_OPTIMIZATION flags were not used by the external
toolchain wrapper, which broke the multilib selection logic of
multilib external toolchains. It also simplifies the compilation of
external programs since all flags are properly passed automatically by
the toolchain wrapper.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
|
|
When an external toolchain has multiple variants organized in
sub-directories, Buildroot only copies the selected sysroot and not
all sysroots. In order to make this work, Buildroot creates a symbolic
link of the name of the original selected sysroot to the main sysroot
to trick the compiler so that it finds its libraries at the expected
location.
I.e, if the toolchain as the following organization (example take on
the ARM CodeSourcery toolchain) :
. for ARMv5T
armv4 for ARMv4T
thumb2 for ARMv7-A/Thumb
and ARMv4T is selected, then Buildroot will copy the contents of
armv4t/ from the toolchain into its $(STAGING_DIR) and then create a
$(STAGING_DIR)/armv4t symbolic link to $(STAGING_DIR).
However, our logic to do so only works when there was one directory
level for multilib sysroots. But in the MIPS CodeSourcery toolchain
there are multiple levels. For example, the MIPS16 soft-float
little-endian sysroot variant is in mips16/soft-float/el/ compared to
the main sysroot.
This patch improves our logic to support this case. The logic is a bit
more complicated as we don't want to create a symbolic link to an
absolute path, but a symbolic link to a relative path, because we want
the host/ directory to be relocatable.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
|
|
The IA32 Sourcery CodeBench toolchain has a relatively special
structure, with the following multilib variants:
* Intel Pentium 4, 32 bits, the multilib variant is in ./ relative to
the main sysroot, with the libraries in the lib/ directory.
* Intel Xeon Nocona, 64 bits, the multilib variant is in ./ relative
to the main sysroot, with the libraries in the lib64/ directory.
* Intel Atom 32 bits, the multilib variant is in atom/ relative to
the main sysroot, with the libraries in the lib/ directory.
* Intel Core 2 64 bits, the multilib variant is in core2/ relative to
the main sysroot, with the libraries in lib64/ directory.
So the first two variants are in the same sysroot, only the name of
the directory for the libraries is different.
Therefore, we introduce a new ARCH_LIB_DIR variable, which contains
either 'lib' or 'lib64'. This variable is defined according to the
location of the libc.a file for the selected multilib variant, and is
then used when copying the libraries to the target and to the staging
directory.
In addition to this, we no longer use the -print-multi-directory to
get the ARCH_SUBDIR, since in the case of the 64 bits variants of this
toolchain, it returns just '64' and not a real path. Instead, we
simply compute the difference between the arch-specific sysroot and
the main sysroot.
We also take that opportunity to expand the documentation on the
meaning of the different variables.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
|
|
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
|
|
No need for double dashes - Purely cosmetical.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
|
|
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
|
|
Fixes build on E.G. powerpc.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
|
|
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
|
|
As suggested by Arnout Vandecappelle, move toolchain/dependencies to
support/dependencies, as it really is not toolchain-specific anymore.
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
|
|
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
|
|
Similar to how we do it for gcc.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
|
|
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
|
|
With default values so it doesn't stop build and ask user. Also disable
2.4 modules support by default like upstream does.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
|
|
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
|
|
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
|
|
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
|
|
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
|
|
Similar to how we do for target (ee39d53ce3ee (Fix GDB BFD test linking)).
Gdb comes with an embedded copy of libiberty, but binutils also installs
libiberty.a into HOST_DIR. The gdb configure script tries to link against
this one rather than the gdb version when it checks for ELF support.
This may fail if those versions are not compatible, leading to obscure
error messages from gdb at runtime such as:
I'm sorry, Dave, I can't do that. Symbol format `elf32-$ARCH' unknown.
Fix it by forcing ELF support.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
|
|
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
|
|
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
|
|
So the uClibc configurations are kept in sync between the two toolchain
methods.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
|
|
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
|
|
Now that we have dropped the make-write-deps patch.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
|
|
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
|
|
Bump 3.0.x series to 3.0.17, 3.1.x series to 3.1.9 and 3.2.x series to
3.2.1
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
|
|
Has been marked as broken since July 2010 (39e6ba1b), and nobody has
stepped up to support it, so now finally remove it completely.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
|
|
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
|
|
Add the ability for buildroot to build an SPE ABI enabled toolchain.
This is mandatory for e500v1/v2 cores since they don't support classic
FPU mode as the e500mc does.
Useful for Freescale's PowerQUICC III and single/dual-core QorIQ
line of processors.
The new TARGET_ABI variable is used rather than TARGET_CFLAGS for
uclibc's UCLIBC_EXTRA_CFLAGS to avoid breakish CFLAGS leaking in, a
good example being -mthumb for ARM.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
|
|
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
|
|
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
|
|
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
|
|
[Peter: rename headers_install patch so it gets applied]
Signed-off-by: Sven Neumann <s.neumann@raumfeld.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
|
|
We unfortunately cannot remove the avr32 variant yet.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
|
|
The 4.3.x series is getting quite old, so let's use 4.5 instead.
There were reports of problems in the past, which is why this is done
early in the cycle.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
|