Decimal floats need support form the C library, namely support
for fenv, which is missing in uClibc for any architecture but
x86/32.
Add an option (a choice) to enable or disable decimal floats.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Support for fenv.h is a little bit more tricky that enabling it only
for x86-32 is not right.
Add an option for the user to choose whther to install fenv.h or not.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Do to glibc what we did to eglibc in #dff359adf15c.
Only (very) old versions of glibc have other external addons,
and they are no longer meaningful.
But for consistency, do the change nonetheless.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
When trying to extract an already present (aka bundled) addon,
print the name of that addon, for clarity, and to help analyse
the build.log post-mortem.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Since gcc 4.8 C++ is also used as implementation language (see gcc
release notes).
Signed-off-by: "Daniel Dittmann" <ddittmann@gmx.net>
Message-Id: <acc7d11bc77b30f21c5b.1388863298@bernalk.machteam>
Patchwork-Id: 306883
gcc-4.8 comes with a new library to sanitise memory access:
- heap-, stack-, and global-buffer overflow, use-after-free
- data-races between threads
This library requires some _np parts of the API, which are not
implemented in the (old) LinuxThreads, which is still available
in uClibc.
Since NPTL requires a i486 or above, i386 are stuck with using LT,
which precludes building the libsanitizer.
Disable libsanitizer, a bit like libatomic is.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Niels Penneman <niels@penneman.org>
For the versions of eglibc where the ports addon is not external (ie,
all versions after, and including 2.17), we would fail to download the
localedef addon, since the test did not care about the addon we were
about to download, only whether the ports addon was external or not.
Fix that by skipping the ports addon only if that's the addon we're
trying to download.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cset 3b61be3d7aa6 (prepare for arch whose kenel name is not the standard name)
failed to name a variable consistently, so all archs but arm64 were broken.
Fix that by renaming the variable in a consistent way.
Reported-by: Maxime Hadjinlian <maxime.hadjinlian@gmail.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
AArch64 id the 64-bit variant for ARM.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Zhenqiang Chen <zhenqiang.chen@linaro.org>
Cc: Michael Hope <michael.hope@linaro.org>
For some architectures, the kernel architecture name is not the common
name of the architecture for other tools.
For example: ARM 64-bit is commonly referenced as aarch64, but the kernel
calls it arm64.
Signed-off-by: Michael Hope <michael.hope@linaro.org>
Signed-off-by: Zhenqiang Chen <zhenqiang.chen@linaro.org>
[yann.morin.1998@free.fr: split out of the aarch64 patch]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Some of the avr32headers related variables are used in different
functions, so have to be declared globally, not locally.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Don't download glibc-ports when glibc or eglibc version greater than 2.16,
because the "ports" source is mainline in the glibc or eglibc since version 2.17.
Signed-off-by: "Daniel Zimmermann" <netzimme@gmail.com>
Message-Id: <9c045ca3cf1b9dc89da3.1384602843@haus-VirtualBox>
Patchwork-Id: 291766
[yann.morin.1998@free.fr: slightly tweak subject, change variable name]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Building the cross-gdb shoud be done using the host compiler,
not the native compiler.
Reported-by: Per Arnold Blaasmo <per-arnold.blaasmo@atmel.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
In case ${CT_LIBC_GLIBC_CONFIGPARMS} starts with a dash, printf will try
to interpret it as an option for itself, and will invariably flail in
panic as it does not recognise any of it.
Use a more robust solution, as suggested by Cody.
Reported-by: "Roberto A. Foglietta" <roberto.foglietta@gmail.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Cody P Schafer <devel-lists@codyps.com>
Add well-known HTTP mirror as a fallback. This lets crosstool-ng
work when behind a HTTP/HTTPS only proxy.
Signed-off-by: Michael Hope <michaelh@juju.net.nz>
[me: split original patch in two]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Message-Id: <aeb4a850d0786ee62dc2.1375559989@wanda>
Patchwork-Id: 264436
Add well-known HTTP mirror as a fallback. This lets crosstool-ng
work when behind a HTTP/HTTPS only proxy.
Signed-off-by: Michael Hope <michaelh@juju.net.nz>
[yann.morin.1998@free.fr: split patch in two]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Message-Id: <aeb4a850d0786ee62dc2.1375559989@wanda>
Patchwork-Id: 264436
CLooG 0.18+ will use ISL instead of PPL, so we have to configure
adequately depending of which backend is in use.
The Kconfig entries will decide for us which is selected, so we
can rely on either PPL xor ISL to be selected, not both.
Reported-by: "Plotnikov Dmitry" <leitz@ispras.ru>
[Dmitry did a preliminray patch to add ISL support,
which this patch is inspired from]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
This means:
- introduce the new symbols for 4.8
- do not always select PPL if graphite is selected
Reported-by: "Plotnikov Dmitry" <leitz@ispras.ru>
[Dmitry did a preliminray patch to add gcc-4.8 support,
which this patch is inspired from]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
ISL is used by gcc-4.8 onward for GRAPHITE, so is also used as
backend for CLooG 0.18.0 onward.
Reported-by: "Plotnikov Dmitry" <leitz@ispras.ru>
[Dmitry did a preliminray patch to add ISL, which this one is inspired from]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
>From 4.8, g++ is used as the default compiler to build the toolchain.
Signed-off-by: Zhenqiang Chen <zhenqiang.chen@linaro.org>
Message-Id: <CACgzC7B-LQvAw3hOYhBA7b7g0H1WtH20gqXM=Y=YFO4FrnZKWQ@mail.gmail.com>
Patchwork-Id: 243590
Building cross-tool based on gcc-4.8 fails while "Installing
pass-2 core C compiler", because building libgcc.mvars needs
libbacktrace.a that gcc.sh doesn't build. This patch inserts
a few lines configuring, and making libbacktrace into gcc.sh
to build gcc-4.8-based cross-tools successfully.
Reported-by: Plotnikov Dmitry <leitz@ispras.ru>
Signed-off-by: Jongsung Kim <neidhard.kim@lge.com>
Message-Id: <201305031831.33395.neidhard.kim@lge.com>
Patchwork-Id: 241258
-fpermissive is not a valid option to gcc.
Adding it to the CFLAGS make the ppl checks fail with the following
error:
[ALL ] Making check in tests
[ALL ] cc1: warnings being treated as errors
[ERROR] cc1: error: command line option "-fpermissive" is valid for C++/ObjC++ but not for C
[ALL ] cc1: warnings being treated as errors
[ERROR] cc1: error: command line option "-fpermissive" is valid for C++/ObjC++ but not for C
[ERROR] make[7]: *** [formatted_output.o] Error 1
Signed-off-by: "Samuel Martin" <smartin@aldebaran-robotics.com>
Message-Id: <bba2482a06a11415207e.1365876457@smartin-de-2.aldebaran.lan>
Patchwork-Id: 236383
This patch fixes the download of the avr32 headers in crosstool-ng by
fetching them directly from Atmel's web site instead of the now-broken URL
given by the original author of the avr32-header-fetching modification,
who fetched them from a copy on his own, now-defunct server.
It also adds the necessary logic to extract from a zip file, as that is
how the headers are packaged.
To configure it for avr32 after launching ct-ng menuconfig in an empty
directory:
Paths and misc options ->
Shell to use as CONFIG_SHELL = sh
Target options ->
Target Architecture = avr32
Toolchain options ->
Tuple's alias = avr32
Binary utilities ->
binutils version = 2.18a
C compiler
gcc version = 4.2.2
C-library
newlib version = 1.17.0
Enable IOs on long long = yes
Enable IOs on floats and doubles = yes
Disable the syscalls supplied with newlib = yes
CONFIG_SHELL is necessary to get round the "fragment: command not
found" bug when binutils-2.18 is configured using bash.
Prepared against crosstool-ng mercurial trunk on 31 March 2012.
Signed-off-by: Martin Guy <martinwguy@gmail.com>
[yann.morin.1998@free.fr: update bundles sample accordingly]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Message-Id: <CAL4-wQrg_NQ7jm-NCADqeyQr9twyhtx42OUGNThP6gWeqZc=kw@mail.gmail.com>
Patchwork-Id: 232612
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Rafael C <groups.r2@gmail.com>
Cc: Jérôme BARDON <bardon.pro@gmail.com>
Cc: Daniel Price <daniel.price@gmail.com>
Reported-by: Rafael C <groups.r2@gmail.com>
Reported-by: Jérôme BARDON <bardon.pro@gmail.com>
Reported-by: Daniel Price <daniel.price@gmail.com>
[yann.morin.1998@free.fr: use a conditional approach, also suggested by Daniel]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
There's no point in not supporting XML in the cross-gdb.
I mean, come on... ;-)
It's still the responsibility of the user to have the necessary
devel expat packages installed for his/her distro.
Reported-by: Trevor Woerner <twoerner@gmail.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
For the native-gdb (ie on the target), we unconditionally
need to build expat.
Make it a backend, it makes a litle bit cleaner code.
Reported-by: Trevor Woerner <twoerner@gmail.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
It should be used only to decide whether we need to download/extract
ncurses, not wheter we should build it or not.
Reported-by: Trevor Woerner <twoerner@gmail.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Rename those three variables to properly reflect their purpose: decide
whether we need to download/extract gdb/libexpat/libncurses, not whether
we need to build them or not.
This is only a rename for now, subsequent changes will further
fix this mess.
Reported-by: Trevor Woerner <twoerner@gmail.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
The menu system provides an option to allow a user to request newlib
version 2.0.0. newlib-2.0.0, however, is not available at the download
location currently being used. It is, however, available (as are other
supported versions of newlib) at an alternate location.
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
Message-Id: <75ab5151c7f5dc9086e3.1362334313@suse64>
Patchwork-Id: 224561
For some architectures, it is legit to have an alternate value in the
'architecture' part of the tuple. For example:
armv5te-*
armv7a8-*
Besides, some packages expect the tuple to reflect the arch variant
(eg. openMPI) to detect the variant's capabilities (eg. atomic
primitives).
This patch adds an option for the user to specify a suffix to be added
to the arch-part of the tuple.
Signed-off-by: Willy Tarreau <w@1wt.eu>
Message-ID: <20130120225822.GS6838@1wt.eu>
Patch-Id: 213994
[yann.morin.1998@free.fr: make it a suffix, not an override]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Toolchains that use the hard-float ABI now are to be denoted by a tuple
ending in *eabihf, while the prevbious *eabi is now an indication that
the toolchain uses the softfloat ABI.
This is purely a cosmetic thing, for distros to differentiate their
hardfloat-ABI ports from their softfloat-ABI ports.
(note: softfloat ABI does not mean that it is using softfloats; it can
be using hardfloat instructions, but using the softfloat ABI).
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Well, all eglibc version we support do, and latest glibc versions
we support do.
Not all glibc versions do, but older versions simply ignore the
unrecognised ./configure flags.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Since unrecognised ./configure flags are simply ignored,
we can always pass --enable-obsolete-rpc.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
ppl-0.10.x does not build with gcc-4.6+, as it uses constructs that were
warnings with gcc-4.5 and before, but are now errors with gcc-4.6 and
above.
Fix that by passing -fpermissive in CFLAGS for ppl 0.10.
Reported-by: Jeremy Rosen <jeremy.rosen@openwide.fr>
Reported-by: Peter Korsgaard <jacmet@uclibc.org>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
In gcc-'s core and final passes, do not print 'core' or 'final' in
log messages. We already print it in step messages.
Also, as we use the core backend to build the bare-metal final gcc,
it can be disturbing to read 'core' while we're in fact in 'final'.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
