Since 11017f081f, the Crosstool-ng
backend generates toolchains that have a prefix inconsistent with what
Buildroot expects. Buildroot expects a "buildroot" vendor name, while
Crosstool-NG builds toolchain with the "unknown" vendor name.
This is causing build failure such as:
http://autobuild.buildroot.org/results/15b2c0e50a81b86dd13af684c9254df2bc0df8de/build-end.log
Fix this by changing the vendor part of the tuple used by Crosstool-NG
to "buildroot".
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Yann E. MORIN says:
"Although eglibc can be configured to include/exclude parts of the
features, it seems to not be in wide use, if at all."
Acked-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Luca Ceresoli <luca@lucaceresoli.net>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
As stated in commit 555c2585bf, the
Xtensa architecture has been introduced in 2009 and never changed
since its initial introduction. It requires some special handling that
is a bit annoying, and despite our call to the initial developers, and
the announcement of the deprecation of the architecture during the
2012.05, nothing has happened. Therefore, drop support for this
architecture.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: me
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
BR2_SPARC_TYPE is a hidden configuration option that is only used for
the configuration of uClibc, therefore, we move it from
target/Config.arch.in to toolchain/uClibc/Config.in.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
BR2_ARM_TYPE is a hidden configuration option that is only used for
the configuration of uClibc, therefore, we move it from
target/Config.arch.in to toolchain/uClibc/Config.in.
We also add a comment that explains that this stuff is only useful for
uClibc <= 0.9.32. Starting from 0.9.33, uClibc build process simply
uses the compiler flags to find the ARM processor that should be
used. So, someday, we'll be able to remove this.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Practically speaking, MIPS has three useful ABIs:
* o32 is for 32-bits CPUs, or 64-bit CPUs running only a 32-bit subset
of the instruction set.
* n32 is for 64-bits CPUs only. It has 32-bits pointers and long
integers.
* n64 is for 64-bits CPUs only. It has 64-bits pointers and long
integers.
See http://www.linux-mips.org/wiki/MIPS_ABI_History and
http://www.linux-mips.org/wiki/WhatsWrongWithO32N32N64 for more
details.
So, this commit reworks the Buildroot MIPS support by:
* Add separate mips64/mips64el top-level architectures.
* Renaming the n32 ABI option to BR2_MIPS_NABI32, for consistency
with BR2_MIPS_OABI32.
* Renaming the n64 ABI option to BR2_MIPS_NABI64, for consistency
with BR2_MIPS_OABI32.
* Make the n32 and n64 ABI selections select the BR2_ARCH_IS_64,
since those ABIs are valid on 64-bits CPUs only.
* Removing the o64 ABI, which is practicaly never used.
* Removing the "none" ABI, which really doesn't make sense.
* Introduce the mips64 and mips64el architecture names when a 64-bits
MIPS ABI is choosen. This will fix build issue like
http://autobuild.buildroot.org/results/9b8c5ea86c953a89e85e7b67e9221de41773f652/build-end.log
where gmp was confused by the fact of having a 32 bits architecture
(detected by the mips- architecture part of the tuple) but 64 bits
integer size when compiling.
* Adjust the uclibc.mk logic to support the new mips64/mips64el
architecture names, and take into account the renaming of the ABI
options.
This has been build tested by generating Buildroot toolchains and
compiling a few packages for MIPS o32, MIPS n32 and MIPS n64.
This work is originally based on prior work done by Gustavo Zacarias.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Introduced by 68973cca2 (adjust logic to support Linaro 2012.05)
Reported-by: R Zhong <rzhong@hotmail.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Commit ba92d6ef68 made hard float the
default when Cortex-A8 and Cortex-A9. The problem it was trying to fix
is that the newer Linaro toolchains (2012.05 and 2012.06) are
hard-float, so the default selection of soft-float enabled on ARM
doesn't work for those toolchains.
Unfortunately, not selecting soft-float causes problems with
the Crosstool-NG backend at the moment.
As an intermediate solution, make the soft float option disappear when
using external toolchain: the toolchain will decide by itself whether
to generate hard float or soft float code.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Instead of having two separate list of choices for select the target
architecture variant for i386 and x86_64, with many CPU choices
duplicated (because all modern x86 CPUs can be both used as i386 or
x86_64), merge them into a single list. In the x86_64 case, all the
x86 CPUs that do not support the 64 bits instruction set are hidden.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
All the defconfig files used by the autobuilders that use
pre-installed external toolchains are making the assumption that the
default for a custom external toolchain is "pre-installed". We keep
this default for now, since changing it breaks the autobuilders.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cortex-A8 and Cortex-A9 ARM cores are guaranteed to provide a hardware
floating point unit, so there's no reason to default to software
floating point for them.
More importantly, the newest Linaro toolchains are hard float
toolchains, so basically an user choosing those toolchains and leaving
the default option of software float would run in compilation issues.
So let's make hard float the default for Cortex-A8 and Cortex-A9.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The check_glibc function verifies that the C library of the external
toolchain is glibc. To do so, it verified that a file matching
ld-linux*.so.* or ld.so.* was found in the lib/ directory of the
toolchain's sysroot. However, with the Linaro 2012.05 toolchain, the
lib/ directory contains two links named ld-linux-armhf.so.3 and
ld-linux.so.3, which means that the first ld-linux*.so.* wildcard
expression expands to two files, which generates a syntax error for
the "test" program. We replace that with a more elaborate find+wc
combination to determine whether at least one matching file is
present.
The check_arm_abi function verifies the ABI of an ARM toolchain. For
EABI, it tested that the target name ends with eabi. However, with
Linaro 2012.05, the tuple is now arm-linux-gnueabihf (for hard float),
so we have to adjust the logic to accept this additional "hf"
specification in the tuple.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Line-up with changes from commit 3367d5ce77
"external-toolchain: run checks even on extracted toolchains"
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This patch adds the possibility to download a custom external
toolchain, in addition to the existing support of preinstalled custom
external toolchains.
With the modified configuration, the user is presented with the
following options:
- Toolchain type: Buildroot toolchain | External toolchain | Ct-ng toolchain
In case of External toolchain:
- Toolchain: the CodeSourcery toolchains | Custom toolchain
- Toolchain origin: Toolchain to be downloaded and installed | Pre-installed toolchain
In case of Toolchain to be downloaded, the user is presented with:
- Toolchain URL
In case of Pre-installed toolchain, the users sees:
- Toolchain Path
For CodeSourcery toolchains, the toolchain URL field is not used (the
URLs are directly coded in ext-tool.mk).
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Fix the indentation of the external toolchain Config file, where tabs
and spaces are mixed as indentation even within the same block.
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
MIPS EABI is a bare-metal ABI so remove it.
Also fix uClibc to really work with N32 ABI, which used the EABI knob
previously.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Instead of providing two variables, make GNU_TARGET_NAME give the real
target name, and remove REAL_GNU_TARGET_NAME altogether.
Signed-off-by: Richard Braun <rbraun@sceen.net>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Block unsupported processors according to gcc version.
Also remove the comments since we now hide them according to this.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Bump default snapshot gcc version to 4.8-20120429 so that it is newer
than our latest supported version (4.7.0 release).
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Decimal floats were introduced circa gcc-4.2 or -4.3, and requires
the floating-point environement fenv.h in the C library.
The uClibc .config file used by crosstool-NG to build uClibc is the
same as used by the internal buildroot mechanism, and explcitly
disables fenv support.
The quick workaround is to simply disable decimal floats in all
crosstool-NG config files.
In the long run, it might be better to check this situation, and/or
add code and/or options in crosstool-NG to handle this (but it is
much more involved, and this workaround is sane).
Reported-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
CC: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
SUPPORT_LIB_DIR would get resolved to the main buildroot directory for
external toolchains without C++ support, as:
- gcc -print-file-name=<nonexisting-file> returns <nonexisting-file>
- readlink -f <nonexisting-file> returns $PWD/<nonexisting-file>
So fix it by ensuring output of gcc -print-file-name actually exists
before using it.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Update the version of crosstool-Ng used, bump to 1.15.2.
Also, update the bundled config files to match the new version.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Commit 0729b544b3 (Improve external toolchain logic to support IA32
Sourcery CodeBench toolchain) and e1f0804cc (external-toolchain: add
support for recent Linaro toolchains) changed the interface of
copy_toolchain_lib_root, but ctng wasn't updated so libraries weren't
copied to the target.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
In order to use locale support on a Linux system, you need locale data
to be present:
* on a (e)glibc based system, this data is typically in the
/usr/lib/locale/locale-archive file, which can be created and
extended using the localedef program
* on an uClibc based system, the set of supported locales is defined
at build time by an uClibc configuration option.
This patch implements generating locale data for the following cases:
* Internal toolchain
* External toolchain based on (e)glibc. uClibc external toolchains
are not supported, because with uClibc, the set of supported
locales is defined at build time. CodeSourcery and Linaro
toolchains have been tested, Crosstool-NG toolchains are believed
to work properly as well.
* Toolchains built using the Crosstool-NG backend, but only (e)glibc
toolchains.
This feature was runtime tested with internal uClibc toolchain,
CodeSourcery ARM toolchain and Linaro ARM toolchain, thanks to a
simple C program that shows the data and a gettext translated message.
Note that this option differs from the "purge locales" option, which
is responsible for removing translation files and other locale stuff
installed by packages. At some point in the future, we may want to
clarify the respective roles of those options.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
When the crosstool-ng backend is used, host-gawk is built as a
dependency of the crosstool-ng package, and therefore an host 'gawk'
binary is installed in $(HOST_DIR).
When the target gdb package is also selected, this unfortunately leads
to a build failure, as reported on
http://buildroot.humanoidz.org/results/f19c0499d08212d8b5100fa9434e1197092957db/build-end.log.
The problem is that the ./configure of gdb detects gawk in the PATH,
but at compile time, it fails to find gawk. This is due to the fact
that the gdb compilation process is started without the correct path.
This patch fixes this by passing $(TARGET_MAKE_ENV) in the environment
of the gdb compilation process.
A better fix would be to switch gdb to the AUTOTARGETS infrastructure
in the future.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Starting from 2012.03, the Linaro toolchains have separated the GCC
support libraries (libstdc++, libgcc_s) from the sysroot itself. So we
no longer have the case where all libraries are inside the sysroot, as
we had for all the previously supported toolchains.
Therefore, we add some logic to detect if such a separate directory is
used for GCC support libraries, and if it's the case, we make sure
that we take into account this directory when creating our own
sysroot, and when copying libraries to the target filesystem.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Enable uClibc 0.9.33.1 for the SH architecture.
Builds and works fine with the qemu sample config.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Enable AI_ADDRCONFIG support in uClibc otherwise we don't get the
ifaddrs.h header installed and thus lack getifaddrs support.
Quite useful for samba for example so we can use interfaces=eth0 statements in
the configuration file rather than klunkier
interfaces=192.168.1.1/255.255.255.0 ones.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
The support for mklibs has been marked broken since more than a year
and nobody cared to bring it up to a working state.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Re-integrate in gcc-uclibc-4.x.mk things from
toolchain/gcc/Makefile.in that were completely gcc-specific. There was
no reason to pull that when building with other backends than the
internal one.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
The BR2_CONFIGURE_DEVEL_SYSROOT, BR2_CONFIGURE_STAGING_SYSROOT and
BR2_CONFIGURE_BUILD_TOOLS were used only in a few places, and it is in
fact clearer to just use their value in the various places they are
used.
The ultimate goal is to get rid of the toolchain/Makefile.in file.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Add gcc 4.7.0 to the toolchain options.
[Peter: drop 0001-toolchain-gcc-add-4.7.x-series.txt]
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Switch from the strict UCLIBC_HAS_CTYPE_ENFORCED=y to the less
restrictive UCLIBC_HAS_CTYPE_CHECKED=y since it breaks dialog under
certain circumstances (bug #5018).
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
The big-endian microblaze external toolchain is missing vital
characteristics being set, such as LARGEFILE support, IPV6 and so on.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Tested-by: Stephan Hoffmann <sho@reLinux.de>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
The 3.3 kernel headers define the umode_t type within a __KERNEL__
preprocessor ifdef region. This results in a broken kernel header in the
buildroot toolchain.
[Peter: This is discussed upstream here:
https://bugzilla.kernel.org/show_bug.cgi?id=42986
Long term socat/syslinux should stop using this header, but this hasn't
been fixed upstream yet]
Signed-off-by: Simon Dawson <spdawson@gmail.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
It adds very little size overhead as the functions are just wrappers
around utmp, and E.G. systemd needs it.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
While there's some microblaze support in mainline gcc from 4.6.x,
there still seems to be something missing with the uClibc support, so
disable these for now.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Signed-off-by: Alvaro G. M <alvaro.gamez@hazent.com>
Tested-by: Stephan Hoffmann <sho@relinux.de>
Downloading Microblaze LE toolchain works on a clean install
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
This modifies the definition of DOWNLOAD to receive two arguments:
the first one is the full URL of the file to download, whereas the second
(and optional) is the name the file will have once downloaded.
Same thing with the SOURCE_CHECK_WGET and SCP functions.
All calls to these functions have been changed to the shortest form of
the new API, except for toolchains acquisition. Since there is quite a
number of different toolchains this call to DOWNLOAD is better set to the
generic one.
Signed-off-by: Alvaro G. M <alvaro.gamez@hazent.com>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Tested-by: Stephan Hoffmann <sho@relinux.de>
Downloading Microblaze LE toolchain works on a clean install
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
When binutils was converted to the package infrastructure (commit
009407e6b), the variable that elf2flt uses to find the binutils
libraries disappeared. So use HOST_BINUTILS_DIR instead of
BINUTILS_DIR1.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
When an external toolchain is used, it is very likely that it contains
a pre-built version of a gdbserver that has the same version as the
cross-gdb included in the external toolchain. So, we now provide an
option that allows to copy this pre-built gdbserver to the target.
As the location of the gdbserver in the external toolchain is not
standardized, we only support the CodeSourcery and Crosstool-NG
layouts for the moment. Other locations can be added later.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Without the -m64, choosing the x86_64 architecture with a Sourcery external
toolchain will result in a 32-bit rootfs.
Also simplified the help text to reflect this change.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
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>
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>
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>
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>
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>
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>
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>
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>
[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>
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>
Update the uClibc build procedure to accomodate for the new build
system, otherwise it breaks with snapshot versions.
As pointed by linuxjacques on IRC.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Add unshare() syscall support for uClibc 0.9.31 and 0.9.32 series.
This is required by newer versions of iproute2.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Most of the extract tools (gzip/bzip/..) we already check for explicitly
in dependencies.sh (as they are used outside GENTARGETS), but not for
xzcat.
The .xz format is used fairly rarely, and it is likely to not be available
on build hosts, so an explicit (hardcoded) check for it isn't optimal.
Instead, add the inflate tools used to DL_TOOLS_DEPENDENCIES, similar to
how we do it for svn/git/bzr/...
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Modern versions of patch (2.6.1.81 / 85 tested) gets confused by the empty
git trailer referencing uClibc_errno.h (from when patch was forward ported
from 0.9.31), so drop it.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Newer versions of GDB need pthread debugging support if threads are
enabled, which is always the case for glibc but is a configure option
for uClibc.
We have solved this for internal toolchains by selecting the
BR2_PTHREAD_DEBUG option from the GDB selection if needed, but as this
option isn't available when ctng/external toolchains are used, mconf
prints ugly warnings and the build may fail if an external uClibc
toolchain without pthread debugging support is used.
Fix it by introducing 2 more hidden config options:
- BR2_TOOLCHAIN_HAS_THREADS_DEBUG
- BR2_TOOLCHAIN_HAS_THREADS_DEBUG_IF_NEEDED
The first tells us if the toolchain HAS pthreads debugging support,
and is checked by check_uclibc_feature in helper.mk for external uClibc
based toolchains.
The second tells us if the toolchain is ABLE TO provide pthreads debugging
support if threads are enabled, either because it's an internal toolchain
where we can force enable it or an external glibc/eglibc toolchain or
uClibc with the option enabled.
Crosstool-ng forcibly enables this support, so those will always work.
The preconfigured uClibc-based toolchains we have also all enable it.
Finally, show a comment if this isn't the case so the (external toolchain)
user knows why. This is placed outside the choice option, as menuconfig
has a bug where it doesn't show choice selections which only contain
comments.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Files package/lzma/lzmacheck.sh and toolchain/dependencies/check-host-lzma.sh
are present since the very beginning of buildroot, but do not appear to be
used (anymore). Let's remove them.
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Currently, the dependencies target (that runs dependencies.sh) depends on
DEPENDENCIES_HOST_PREREQ. This means that the dependencies listed in
DEPENDENCIES_HOST_PREREQ (currently host-sstrip if sstrip is selected) are
built *before* the dependencies.sh script is run.
As a result, if e.g. there is no gcc compiler present on the build system, the
dependencies in DEPENDENCIES_HOST_PREREQ will fail to build, and buildroot
will fail non-gracefully.
This patch makes sure that the DEPENDENCIES_HOST_PREREQ are checked *after* the
dependencies.sh script, so that any problem in the build system is reported in
a clean way by dependencies.sh.
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Closes#4021
Fix build breakage for sparc as reported in bug #4021
Patches from Konrad Eisele <konrad@gaisler.com>
Submitted in the uclibc mailing list.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Compiling gdb for the target requires thread support in the C library,
otherwise:
/home/test/outputs/test-888/toolchain/gdb-7.3.1/gdb/gdb_thread_db.h:37:21: fatal error: pthread.h: No such file or directory
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
The gdb debugger does not have support for running as the native
debugger on the SuperH architecture:
configure: error: "*** Gdb does not support native target sh4-unknown-linux-gnu"
See also http://lists.debian.org/debian-superh/2010/04/msg00000.html.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
The original name uclibc-update is confusing as it only updates a
configuration file.
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
When using a CT-NG toolchain as external toolchain (not with the
integration) and said toolchain has u-w directories rsync fails.
So instruct rsync to chmod u+w directories in the target copy to avoid
the issue.
[Peter: notice that this is a workaround for a rsync 3.0.8 bug]
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Permit to define the mcpu of the external toolchain wrapper, based on
BR2_GCC_TARGET_CPU.
Signed-off-by: Stany MARCEL <stanypub@gmail.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
When the external tools chain is installed in a path that match one of
the first case test, all symlink are created to the external
wrapper. The proposed solution is to test only the base name not the
full path.
Signed-off-by: Stany MARCEL <stanypub@gmail.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Update the version in the package description. Update the default
configuration files for the three different C libraries.
[Peter: Removed unneeded changes as noticed by Baruch Siach]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
When the user has Perl local::lib installed, its environment contains
a PERL_MM_OPT variables which defines
INSTALL_BASE="/some/location". Unfortunately, having this makes the
build of libxml-parser-perl (and probably other Perl related packages)
fail, because it complains that both PREFIX (passed in our .mk file)
and INSTALL_BASE (passed from the PERL_MM_OPT environment variable)
are defined. Since in Buildroot we want our PREFIX to be considered,
we error out when the user has PERL_MM_OPT defined.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
The copy_toolchain_lib_root helper searches the entire sysroot, but is
only interested in files in certain subdirs. So rather than waste time
in walking the entire tree, walk the few subdirs at the depth level we
are actually going to be poaching files from.
Some simplification suggested by Yann E. MORIN
<yann.morin.1998@anciens.enib.fr> and Arnout Vandecappelle
<arnout@mind.be>, added by Thomas Petazzoni
<thomas.petazzoni@free-electrons.com>.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Some CodeSourcery toolchains contain a huge number of locales that are
not useful, even though they account for 70-80% of the total toolchain
size. By skipping the extraction of those useless locales, we make the
toolchain extraction process slightly faster, and also make the output
directory size a lot smaller (host/opt/ is 213 MB instead of 1.5 GB
with a 2010.09 ARM CodeSourcery toolchain).
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Now that CodeSourcery has been bought by Mentor Graphics, the
toolchains are named "Sourcery CodeBench". We rename the config short
description and adjust the help text, but we keep the option name in
order not to break existing configurations.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
