As posted on http://www.eglibc.org/
====================
EGLIBC is no longer developed and such goals are now being addressed
directly in GLIBC.
====================
I'm not interested in maintaining build support for unsupported
software.
Older branches of crosstool-ng continue to have eglibc support.
If you find issues with older branches, I'm always open to pull
requests.
Removing eglibc also frees up glibc cleanup and build optimization.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
This script has a '#!/bin/sh' shabang and might be running on a POSIX
shell. So replace bash-specific constructions (pushd/popd, for((...)),
read with '-u' option) to POSIX-shell equivalents.
Signed-off-by: Led ledest@gmail.com
We had following problem: We're building a toolchain with an old glibc
version for compatibility with old Linux distributions (glibc 2.9). This
version requires make < 4 to build. However, the configure script of
glibc looks for make in the order "gnumake", "gmake" and "make". So when
"gmake" is available in the system (which is the case on Gentoo Linux
per default, unfortunately), then configure finds the system gmake 4.1
instead of the ct-ng make 3.82.
This patch adds an option to install a symlink so that 'gmake' is also
available in the old version when building toolchains.
Signed-off-by: Bernhard Walle <bernhard@bwalle.de>
Canadian Cross compile for baremetal fails with error;
checking for the value of EOF... configure: error: computing EOF failed
which is due to libstdc++ configure not being able to find stdio.h
Having all modes of the core compiler copyheaders from CT_HEADERS_DIR
(in combination with previous patch for newlib to add a do_libc_start_files
function to copy into the CT_HEADERS_DIR) resolves this.
Signed-off-by: David Holsgrove <david.holsgrove@xilinx.com>
Require access to newlibs headers in gcc.sh, matching other libc components.
Resolves issue with headers not found.
Signed-off-by: David Holsgrove <david.holsgrove@xilinx.com>
Currently, the obsolete RPC headers are only installed for eglibc,
but glibc has the same /deficiency/, so install the obsolete RPC
for both.
Signed-off-by: Jérôme BARDON <bardon.pro@gmail.com>
Signed-off-by: David Holsgrove <david.holsgrove@xilinx.com>
Yes, I missed the backslash which messed up the linaro stuff.
The more I look at this code, I feel it needs to be refactored a bit. So
I'll come back to this in the future and clean it up.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
It's not my day.
linaro_version is a filter. If it is not a linaro toolchain, it will
just be CT_{CC,GDB}_VERSION. If it is a linaro toolchain, CT_{CC,GDB}_VERSION
will be prefixed with 'linaro-' and will not match linaro_version, as
linaro_version will just have the part after 'linaro-'.
This *really* fixes the issue :sigh:
Thanks again to @elsonwei for being right the first time!
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
linaro_version and linaro_series are defined but not set if we are not
configured for linaro builds.
Therefore we need to default them to "" (null string).
As reported by @elsonwei
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
If custom {e}glibc is being used, no need to carry out the
extract or patching phase of scripts/build/libc/glibc-eglibc.sh-common
Signed-off-by: David Holsgrove <david.holsgrove@xilinx.com>
CUSTOM_LOCATION config options only presented in menuconfig if component
CUSTOM version selected.
Signed-off-by: David Holsgrove <david.holsgrove@xilinx.com>
CUSTOM_LOCATION config options only presented in menuconfig if component
CUSTOM version selected.
Signed-off-by: David Holsgrove <david.holsgrove@xilinx.com>
No longer recommended practice to use --enable-add-ons=nptl, so
for 2.20 and later (along with custom glibc), don't add the
CT_THREADS to the addons_list
https://sourceware.org/glibc/wiki/Release/2.20#Packaging_Changes
Signed-off-by: David Holsgrove <david.holsgrove@xilinx.com>
This change updates the download locations to default to the official
download site.
For gcc and gdb, also separate out the linaro download locations so that
if you are downloading the linaro variant, it skips trying to download
from the official gcc mirror.
This commit closes#3
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
Reported-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Without this fix, elf2flt will blow up complaining that it can't resolve
dlopen() and friends. One has to explicitly pass '-ldl' on the final
linking command line, because the system linker is not resolving
indirect dependent shared libraries.
I've needed to this patch for several years on Fedora systems.
Signed-off-by: Solomon Peachy <pizza@shaftnet.org>
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
When try to build the static toolchain, binutils failed.
I have checked the libtool script, and found that the following option
-all-static
-static
-static-libtool-libs
are processed in a strange way. If any one of those three options
appears firstly in the cmdline, all others will be neglected. Our
LDFLAGS is ".... -static -all-static -o", so the -static option
takes the real effect, and the -all-static has no useage actually!
that is the cause of the failure.
Signed-off-by: Brock Zheng <goodmenlinux@gmail.com>
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
BSD grep does not interpret a null alteration. It complains about an
empty sub-expression, e.g.:
$ grep --version && grep -E '^(# |)CT_' .config
grep (BSD grep) 2.5.1-FreeBSD
grep: empty (sub)expression
This patch replaces the null alteration with a zero or once quantifier
which works with both BSD & GNU grep.
$ grep --version && grep -E '^(# )?CT_' .config
grep (BSD grep) 2.5.1-FreeBSD
CT_CONFIGURE_has_xz=y
CT_CONFIGURE_has_svn=y
...
$ ggrep --version && ggrep -E '^(# )?CT_' .config
ggrep (GNU grep) 2.20
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Written by Mike Haertel and others, see
<http://git.sv.gnu.org/cgit/grep.git/tree/AUTHORS>.
CT_CONFIGURE_has_xz=y
CT_CONFIGURE_has_svn=y
...
Signed-off-by: Jason T. Masker <jason@masker.net>
Tested-by: Andreas Bießmann <andreas@biessmann.de>
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
The output format of the file(1) command have changed since (at least)
the version 5.14. We need to to take care of an extra space.
Signed-off-by: Jean-Marie Lemetayer <jeanmarie.lemetayer@gmail.com>
[yann.morin.1998@free.fr: do not right-shift trailing back-slashes]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
This commit adds a configuration knob for enabling extra developer
warnings to be enabled during the musl-libc build.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
This option enables a configuration knob for adding debugging info.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Byt the end of the main script, the log file is being moved and
compressed, and the final destination might become read-only at any
time, so we consign stdout/err to oblivion.
This is incorrect, as some actions after may still fail (out of space,
for example).
So, properly restore stdout/err, but also stdin (useless, but harmless)
instead, so the user has a chance to see the error, especially since it
is not logged into the log file.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
libsaniotizer requires a few headers that are not in uClibc, for
example. Also, it is only available for native threads (NPTL under
glibc.) Finally, it is only available starting with gcc-4.8.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
This patch adds initial support for musl-libc.
Musl-libc versions currently supported:
* 1.0.3 (Stable)
* 1.1.3 (Previous Mainline)
* 1.1.4 (Mainline)
Futher improvements are needed.
* gcc-4.9.x has issues (Might be fixed in musl-1.1.4).
* Multilib support is needed.
* Checks to make sure paths are correct.
* Move to 2-step gcc build. 3-step build is not necessary.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
[yann.morin.1998@free.fr: removed the gcc musl patch, to be added later;
removed dead code do_get_arch()]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
This change adds support for experimental patches to be introduced to
crosstool-ng. The patches enabled by this option are to be located here:
patches/experimental/<package>/<version>/XXXX-NAME.patch
Where, XXXX is the patch number to be applied in order, like:
0001-some_patch_one.patch
0002-some_patch_two.patch
9999-some_patch_to_be_applied_last.patch
In the first patch series, all patches in the EXPERIMENTAL_PATCHES
option will be applied all at once, or none at all.
In a later [RFC] patch, I plan on adding finer tuned patch
enable/disable options based on the name of the patch and where it is
located in the patches/experimental sub-tree. So the name of the patch
should use underscores between words in the patch name.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
[yann.morin.1998@free.fr: slightly reword prompt]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
The previous patch (cset b61a1b1, cc/gcc: avoid passing --enable-multilib)
only fixed the core backend, and missed the final backend.
This patch does the same as b61a1b1, but for the final backend.
Signed-off-by: Cody P Schafer <dev@codyps.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
This script is too Hg-specific. Just remove it.
In case we need something similar in the future,
we'd just have to use the better git counterparts.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
This script is too Hg-specific. Just remove it.
In case we need something similar in the future,
we'd just have to use the better git counterparts.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Technically, I don't forbid powerpcle support either, but I'm not sure that
there is any library/compiler support for that at the moment (though the hw
technically makes it possible).
powerpc64le needs glibc 2.19 and gcc 4.9. I haven't looked into the support
tools, but at least gdb 7.5 is too old (7.7.1 definitely has support).
Also make powerpc64 non-experimental. It's practically old at this point.
Signed-off-by: Cody P Schafer <dev@codyps.com>
[yann.morin.1998@free.fr: use ${target_endian_le} and ${target_bits_64}]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Message-Id: <64bfbbced9dd8f62e0d6.1399801945@gun>
Patchwork-Id: 347775
These variables behave the same for bitness as their counterparts do
for endianness: they are defined to the appropriate bitness.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Cody P Schafer <dev@codyps.com>
We currently define target_endian_el and target_endian_eb to be the
tuple extension depending on endianness, defined to be respectively
'el' or 'eb' according to the endianness.
Some architecture do not use 'el' or 'eb', but use 'le' or 'be'.
Provide that as well, as two new variables: target_endian_le and
target_endian_be.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Cody P Schafer <dev@codyps.com>
In case we're using a custom (aka local) binutils source, we still
need to extract and patch elf2flt.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
The final bare-metal compiler is built using the core backend.
Currently the core uses the CC_CORE_EXTRA_CONFIG_ARRAY variable.
While this works as supposed to, this can leave the user puzzled
in the menuconfig, since all he can see is the core options, not
the final options.
Only show the core options if any of the core passes are needed,
and use the final options in the core-backend if we're issuing
the bare-metal compiler.
Signed-off-by: Cody P Schafer <dev@codyps.com>
[yann.morin.1998@free.fr: hide core options if no core pass needed;
use final option in core backend if issuing the bare-metal compiler]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Message-Id: <22181e546ba746202489.1399688067@localhost>
Patchwork-Id: 347586
Some versions of gcc have a broken --enable-multilib flag. As multilib is the
default, only pass the --disable-multilib flag
Signed-off-by: Cody P Schafer <dev@codyps.com>
[yann.morin.1998@free.fr: make it an if-block; duplicate commit log as comment]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Message-Id: <5c970c1ceb22528fe28a.1399687923@localhost>
Patchwork-Id: 347585
Allow '-1' to be specified as CONNECTION_TIMEOUT to disable the use
of the connection timeout for wget.
Signed-off-by: Cody P Schafer <dev@codyps.com>
Message-Id: <cb33f8c2cbaf802d4f04.1399687632@localhost>
Patchwork-Id: 347582
newlib: fix extract process for custom version
If the user specifies the use of a custom newlib version, the logic in the
extract function was reversed, so this step would fail.
Signed-off-by: Trevor Woerner <trevor.woerner@linaro.org>
[yann.morin.1998@free.fr: keep leading indentation]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Message-Id: <c727adf1b7bd2c1e891d.1393353347@openSUSE-i7>
Patchwork-Id: 324060
We now know exactly what pass to build, so build only what is required.
Reported-by: Trevor Woerner <trevor.woerner@linaro.org>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
so that it is available to available to
the core C compiler build because static
libraries are built and ranlib is used
on them.
Signed-off-by: Ray Donnelly <mingw.android@gmail.com>
Message-Id: <CAOYw7dt=+DdnKAHNShfs6a+=7sS+DLQYkyxnQMAwmw7E7zqvgA@mail.gmail.com>
Patchwork-Id: 316477
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>
The comma is used by the autotools as separator in many sed expressions,
which break if a directory contains commas.
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>
'zcat' on MacOS-X is broken (it is not gzip's zcat, but compres' zcat).
Use 'gzip -dc' for portability, as suggested by Anthony.
Reported-by: Fernando Ortiz <fortiz2k@gmail.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Anthony Foiani <anthony.foiani@gmail.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
In case we only download or extract the sources, do not fail while
finishing the toolchain: the test-suite directory may not exist, so
we can't chmod it.
Also, use safer constructs that won't trigger the 'set -e' in case of
failure (eg.: "[ ... ] && ..." is not safe in case the test fails).
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
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>
Running as root is really, really dangerous.
Add a runtime-check that refuses to build if running as root.
Can be overriden with a double switch in the menuconfig.
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>
The one was missing from the list.
It is very improbable that we ever need it, as elf2flt does no release,
and we always get it from CVS head. But for the sake of consistency, we
just add it.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
While most components have their version in the .in file, some
have it in the .in.2 (eg. elf2flt).
Currently, to handle this case, we indiscriminately munge both files,
but this is wrong: in the elf2flt case, if we add a binutils version,
we do not want it to be added to elf2flt, and conversely.
So, for each tool, we need to explicitly know what file to munge.
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>
Since we've had the debug shell feature, fd #7 is now used to
redirect stderr, while it was previously unused.
Use fd #9 to redirect stdout.
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>
xldd uses sed and grep as detected by ./configure. This works well if is
used on the machine that build the toolchain.
But if the user moves the toolchain to another machine where sed and grep
are not in the same directory (eg. /bin/sed vs. /usr/bin/sed), then xldd
will stop functionning.
Fix that by using ${SED} and ${GREP} if they are set in the environment.
Reported-by: Samuel Martin <s.martin49@gmail.com>
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>
It is used for skipping unnecessary compilation steps when the libc
doesn't need to be compiled (eg. when we do not use a C library).
Signed-off-by: Yann Diorcet <diorcet.yann@gmail.com>
Message-Id: <150eadb0117e697d79aa.1353625025@blackmint>
Patchwork-Id: 201222
Properly catch resuming the build when continuing past the
failed command.
The 'case ;;&' construct is a bash4ism. Get rid of it.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
The current mechanism to check if static linking is possible, and the mesage
displayed on failure, can be puzzling to the unsuspecting user.
Also, the current implementation is not using the existing infrastructure,
and is thus difficult to enhance with new tests.
So, switch to using the standard CT_DoExecLog infra, and use four tests to
check for the host compiler:
- check we can run it
- check it can build a trivial program
- check it can statically link that program
- check if it statically link with libstdc++
That should cover most of the problems. Hopefully.
(At the same time, fix a typo in a comment)
Signed-off-by: Daniel Price <daniel.price@gmail.com>
[yann.morin.1998@free.fr: split original patch for self-contained changes]
[yann.morin.1998@free.fr: use steps to better see gcc's output]
[yann.morin.1998@free.fr: commit log]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Message-Id: <163f86b5216fc08c672a.1353459722@nipigon.dssd.com>
Patchwork-Id: 200536
Signed-off-by: Daniel Price <daniel.price@gmail.com>
[yann.morin.1998@free.fr: split original patch for self-contained changes]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Message-Id: <163f86b5216fc08c672a.1353459722@nipigon.dssd.com>
Patchwork-Id: 200536
Rework binutils in order to provide soon binutils alternative.
Signed-off-by: Yann Diorcet <diorcet.yann@gmail.com>
[yann.morin.1998@free.fr: split up original patch for self-contained changes]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Message-Id: <d3d1d51f399e6d2c1163.1353320546@macbook-smorlat.local>
Patchwork-Id: 199971
On some hosts, and for certain toolchains (eg. toolchain targetting
the upcoming Darwin), it may be necessary to pass arbitrary CFLAGS
and/or LDFLAGS when building the components.
And necessary infrastructure:
- EXTRA_{CFLAGS,LDFLAGS}_FOR_{BUILD,HOST} as config options
- pass those extra flags to components
Fix-up a slight typo in elf2flt at the same time (misnamed cflags).
Signed-off-by: Yann Diorcet <diorcet.yann@gmail.com>
Message-Id: <d24043276c9243a35421.1353077450@macbook-smorlat.local>
Patchwork-Id: 199645
sstrip has been obsoleted for a while now, as it's still broken
for some archs, and there seems to be no incentive to fix it
upstream. Besides, the space gained with sstrip is marginal at
best.
Signed-off-by: Yann Diorcet <diorcet.yann@gmail.com>
Message-Id: <65c8bf534d0647ce52cd.1353320545@macbook-smorlat.local>
Patchwork-Id: 199970
Use the same method as companion tools for providing generic and
extendable companion libs.
Signed-off-by: Yann Diorcet <diorcet.yann@gmail.com>
Message-Id: <515c5c4635d99ebe4877.1353074410@macbook-smorlat.local>
Patchwork-Id: 199613
Replace the 32-bit-only mingw32 with mingw-w64 that is capable
of building toolchains for both 32-bit and 64-bit Windows.
kernel/mingw: replace mingw32 with generic Windows
kernel/windows: New windows kernel supporting 32 and 64 bit arch
libc/mingw: Remove old options
patches: Remove old mingw libc options' patches
Signed-off-by: "Yann Diorcet" <diorcet.yann@gmail.com>
[yann.morin.1998@free.fr: array var in libc/mingw.sh, typos]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Message-Id: <b045ac08fc9eac2e5ee3.1352898499@blackmint>
Patchwork-Id: 198901
The extra CFLAGS override the product defaults, causing the product to
be built without optimisation or debug. Be explicit and add these in.
Reported-by: Johannes Stezenbach <js@sig21.net>
Signed-off-by: Michael Hope <michael.hope@linaro.org>
Message-Id: <CANLjY-=3Gbio6nzUPhhevDHV7cUN=6Vigooe9nSf-RnGCqnjog@mail.gmail.com>
Patchwork-Id: 198808
While eglibc-2.16 recommends to use TI-RPC instead of the old sunrpc, the
old one can be included using a configure option. Since the user can still
use TI-RPC to override the libc implementation, we enable rpc unconditionally.
Signed-off-by: Johannes Stezenbach <js@sig21.net>
Message-Id: <20121102140404.GA7707@sig21.net>
Patchwork-Id: 196564
We now have the ability to use a custom location, so supporting
snapshots or custom date is no longer needed. Let the user do the
required preparation in this case.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
