In case of bare metal, newlib is built without any syscalls,
and dmalloc fails to link with undefined references to _exit,
fstat, open, sbrk and so on.
Same for DUMA: depends on <memory.h>, not available with newlib.
Signed-off-by: Alexey Neyman <stilor@att.net>
To build uClibc correctly we need correct endianness selected in the
crosstool-NG. Xtensa cores may be little- or big-endian, but this
property is static. The toolchain knows the core endianness and doesn't
need options to select it.
Enable ARCH_SUPPORTS_BOTH_ENDIAN and select LE by default. Specify empty
CT_ARCH_ENDIAN_CFLAG so that -m{big,little}-endian don't get added to
the TARGET_CFLAGS, as it's not supported by gcc. Specify empty
CT_ARCH_ENDIAN_LDFLAG so that -EB/-EL don't get added to the
TARGET_LDFLAGS as they are ignored. Select big-endian in the example
xtensa-unknown-linux-uclibc configuration.
This fixes uClibc toolchain build for little-endian cores.
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Allow selection of make/m4/... version. Support imports of new versions
via addToolVersion.sh. Import newest versions of the companion tools.
One non-trivial change is the handling of make versions. Existing code
was not handling make companion tool as described (see the previous
commit). However, since most modern systems have make 4.x, that previous
commit made crosstool-ng always build make as a companion tool.
This traces back to the commit dd15c93 from 2014. That commit's log message
says that actually it was 3.81 which broke the build for certain component
(it was originally breaking eglibc, but I noticed it was breaking current
glibc on powerpc64), and introduced an option to force using 3.81 by
"components that really need it". It looks like in 2.5 years we haven't
seen any such components that really need make 3.81, and (given that make
has already had a few releases since 3.81) we're unlikely to see them
in the future.
Hence, the configure check is changed from "exactly 3.81" to "3.81 or newer".
In its current form, configure will accept make 3.80+, and will not require
make as a companion tool for 3.81+. We might want to bump the latter check
to even newer version given the claim from dd15c93. Killed
COMP_TOOLS_make_3_81_NEEDED.
Anyway, I retained 3.81 just in case; ditto for m4 1.14.3, autoconf 2.65
and automake 1.11.1.
Signed-off-by: Alexey Neyman <stilor@att.net>
1.0.18 changed the dependencies for the static libraries, notably
in libc/Makefile.in. This resulted in packing a lot of unrelated
stuff into libc.a, including (sic!) a nested .a library and stuff
from other libraries such as libdl. This results in a failure to
statically link with thus created libc.a:
.../libc.a(libdl.os):(.literal+0x74): undefined reference to `_dl_tlsdesc_return'
This was breaking xtensa-*-uclibc sample.
Signed-off-by: Alexey Neyman <stilor@att.net>
1.0.15 only kept a single LINUXTHREADS option, and renamed it, making it
no longer option-compatible with uClibc.
The option for "1.0.14 or later" version of uClibc-ng is not currently
used; rename it to "1.0.15 or later" and use it to handle newer
uClibc-ng's linuxthreads.
m68k happens to be the only sample using linuxthreads.
Signed-off-by: Alexey Neyman <stilor@att.net>
In preparation for multilib support, use the same "backend" model that
is already employed by glibc and musl.
Also, the verbosity setting descriptions were swapped. V=2 is actually
less verbose than V=1: V=1 prints full commands, while V=2 prints 'CC
<file> <defines>'.
Signed-off-by: Alexey Neyman <stilor@att.net>
- Dump CT_LIBC_EXTRA_CC_ARGS: instead, treat CT_LIBC_EXTRA_CFLAGS as
arguments to CC (or they are not applied to .S, for example).
Combine them with multi_flags and CT_TARGET_CFLAGS in proper order.
- Analyze thus combined flags to determine --with-fp/--without-fp.
Don't need to check CT_ARCH_FLOAT - it is reflected in
CT_TARGET_CFLAGS anyway. Check more soft/hard float options defined
on different architectures.
- Drop checking for endianness flags: they are not reflected in
configure arguments in any way, and they're already present in CFLAGS
(either via multi_flags or via CT_TARGET_CFLAGS). Besides,
CT_ARCH_ENDIAN_OPT was actually called CT_ARCH_ENDIAN_CFLAG, so this
was a no-op anyway.
Signed-off-by: Alexey Neyman <stilor@att.net>
On some arches (e.g. MIPS) the options like -mabi do not work if
specified more than once (see the comment in 100-gcc.sh). Therefore,
we need to determine which of the options produced by <arch>.sh can
be passed to multilib builds and which must be removed (i.e., which
options vary among the multilibs).
This presents a chicken-and-egg problem. GCC developers, in their
infinite wisdom, do not allow arbitrary multilib specification to be
supplied to GCC's configure. Instead, the target (and sometimes some
extra options) determine the set of multilibs - which may include
different CPUs, different ABIs, different endianness, different FPUs,
different floating-point ABIs, ... That is, we don't know which parts
vary until we build GCC and ask it.
So, the solution implemented here is:
- For multilib builds, start with empty CT_ARCH_TARGET_CFLAGS/LDFLAGS.
- For multilib builds, require core pass 1. Pass 1 does not build any
target binaries, so at that point, our target options have not been
used yet.
- Provide an API to modify the environment variables for the steps that
follow the current one.
- As a part of multilib-related housekeeping, determine the variable
part of multilibs and filter out these options; pass the rest into
CT_TARGET_CFLAGS/LDFLAGS.
This still does not handle extra dependencies between GCC options (like
-ma implying -mcpu=X -mtune=Y, etc.) but I feel that would complicate
matters too much. Let's leave this until there's a compelling case for
it.
Also, query GCC's sysroot suffix for targets that use it (SuperH,
for example) - the default multilib may not work if the command line
specifies the default option explicitly (%sysroot_suffix_spec is not
aware of multilib defaults).
Signed-off-by: Alexey Neyman <stilor@att.net>
Written by Bryan Hundven.
Modified by Alexey Neyman to actually add the option to gcc.in.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
Signed-off-by: Ray Donnelly <mingw.android@gmail.com>
Signed-off-by: Alexey Neyman <stilor@att.net>
Now that libc backend installs the libraries into the directory reported
by gcc as 'multi-os-directory', sh4 libraries are installed into a '!m4'
subdirectory. This directory then confuses GNU ld, which assumes the
exclamation mark to be a word separator and attempts to link to
'/usr/lib' (a directory). However, if multilib is enabled, the default
libraries are installed into the [expected] '/usr/lib/./'. This looks
like an artifact of SuperH's unique way of specifying the multilibs to
be built in GCC (which may list exclusions, starting with '!').
Signed-off-by: Alexey Neyman <stilor@att.net>
If EXPERIMENTAL is not set, the only choice for version is the set of
released versions - currently, 1.1.14. But this only option is disabled
because it is also marked EXPERIMENTAL; this leaves no available choices
in the configuration.
Marking MUSL as experimental: it seems to have header issues which
prevent, for example, gdbserver from building. musl copied chunks of
ptrace.h code from the kernel into its own headers, which now clash with
Linux kernel headers. Manifests at least on SH4 target.
Also, musl breaks in powerpc builds: GCC balks at it with "unsupported
DEFAULT_LIBC" message. Also, 64-bit powerpc and mips are not supported.
So, until someone figures out the dependencies for musl in config/, mark
it experimental.
Signed-off-by: Alexey Neyman <stilor@att.net>
The avr-libc project has released version 2.0.0:
http://savannah.nongnu.org/forum/forum.php?forum_id=8460
Apart from changes and bugfixes, this release adds support for gcc 5,
which allows us to build gcc 5 avr toolchains and also to update our avr
sample.
avr-libc 2.0.0 has been build tested both with gcc 4.9.3 and gcc 5.3.0.
Signed-off-by: Erico Nunes <nunes.erico@gmail.com>
GLIBC 2.23 dropped support for pre-v9 SPARC in pthreads. Pass host
triplet with s/sparc/sparcv9/ replacement for 2.23.
Signed-off-by: Alexey Neyman <stilor@att.net>
We now only support glibc >=2.18
This now enables us to clean up glibc support!
Also, add a comment about glibc 2.20 as the point which glibc no longer
supports not building with pthread.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
Kernel revisions updated to match kernel.org.
Update includes removal of 4.2.x kernel (since it was EOL),
addition of 4.4.x kernel, and marking of 4.3.x as EOL.
Signed-off-by: Yogesh Sharma <YogeshASharma@gmail.com>
As crosstools-ng only support GCC >= 4.8 we do not need libelf for gcc. GCC dropped this dependency with 4.6.
Signed-off-by: Matthias Weisser <m.weisser.m@gmail.com>
elf2flt is now hosted on github here:
https://github.com/uclinux-dev/elf2flt
But, until arm support is upstream, we'll switch to Waldemar Brodkorb
version of elf2flt.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
I was noticing that $extra_user_env was inconsistently used in
100-gcc.sh. I don't feel comfortable having just any make flag or
environment variable passed to make from a config file. If a specific
option needs to be passed to make for gcc, then a specific kconfig
option should be added for that make flag/option/env.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
Since older GCC versions have been removed, older versions of binutils
are not needed.
This commit removes these older versions.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
This option allowed you to use a custom headers directory/tarball to use
in your sysroot.
Not to be confused with using a custom source, that option is the
preferred method.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
On top of making <component>_CUSTOM much more complicated to rewrite,
you couldn't depend on a requirement for all of the components to treat
custom sources the same with it around.
If you need a custom source for a component, define it in the component.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Since CUSTOM_LOCATION_ROOT_DIR was removed from config/global/paths.in
in commit c499ccb, xtensa should depend only on it's
ARCH_XTENSA_CUSTOM_OVERLAY_LOCATION.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Instead of checking if thread support is enabled during the build, move
the check to kconfig-time. Since if threading support is not availble,
libgomp should not be available either.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
Now that versions of gcc that required PPL are no longer supported
( >= gcc-4.5.x AND <= gcc-4.7.x )
...we no longer require PPL or CLooG/PPL.
This commit:
* Removes PPL
* Removes CLooG/PPL
* Updates the documentation
* Updates build script for CLooG and GCC
* Removes PPL and CLooG/PPL from scripts/addToolVersion.sh and
scripts/showSamples.sh
* Adds ISL to scripts/addToolVersion.sh and scripts/showSamples.sh
I know that sounds like a lot for one commit, but it was all kind of
inter-tangled.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
As per #222, in crosstool-NG >= 1.23.0, we will only support:
[upstream supported gcc versions] - 1
As of this writing, these versions are:
* 5.2.0
* 4.9.3
* 4.8.5 (the -1, since development on 4.8.x is now closed)
I plan to keep 4.8.5 around because of some architectures having issues
with over-optimization or just faulty optimization in the 4.9.x and
possibly newer versions.
I also cleaned up a requirement for glibc to depend on >= gcc-4.6.x for
>= glibc-2.20, but since the lowest gcc we support after this change is
>= 4.8.5, this condition can go away.
Patches for older gcc versions are removed in the next commit.
This closes#222
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
With the upcoming release of 1.22.0, mingw-w64 is still in an
experimental state, and is not considered to be fully supported yet.
This change should be reverted after the release.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
This commit removes ncurses-5.9 and adds 6.0.
I also provide the stable patch updates in patches/ncurses/6.0.
I have also added an experimental toggle for enabling the new ABI
support.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
In commit c9704c6683, I forgot to bump the
version in the prompt for uClibc-ng-1.0.9.
Reported-by: Reinoud Koornstra <reinoudkoornstra@gmail.com>
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
The configure error mentioned in the commits that disable
--with-arch/--with-tune when --with-cpu is specified is specific to ARM
builds. For other architectures, it makes sense (hey, it even makes
sense for ARM - read 'info gcc'! - it is just a shortcoming of ARM
build, apparently).
Thus, add an arch setting ARCH_EXCLUSIVE_WITH_CPU (currently, set only
for ARM) that will trigger current behavior. Permit combinations of
--with-arch/cpu/tune for other arches.
Signed-off-by: Alexey Neyman <stilor@att.net>
Currently, builds for build and target (matching the current
implementation). Need to add building for host for canadian crosses.
TIC_PATH is removed - configure in ncurses searches $PATH, so it finds
'tic' in buildtools anyway. Arguably unneeded code for MacOS also
removed, with a FIXME comment for validation by someone using MacOS.
Signed-off-by: Alexey Neyman <stilor@att.net>
I was going to start doing some autoconf work, and noticed that
configure.in was executable. Then I noticed Makefile.in was executable.
o.O
So, I ran ```find . -type f -executable``` and found a bunch of files
that shouldn't be set executable.
This commit makes them normal files again.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
The Xtensa processor architecture is a configurable, extensible,
and synthesizable 32-bit RISC processor core. Processor and SOC vendors
can select from various processor options and even create customized
instructions in addition to a base ISA to tailor the processor for
a particular application.
Because of the configurability, the build process requires one additional
step for gcc, binutils, and gdb to update the default configuration.
These configurations are packed into an 'overlay' tar image, and are
simply untarred on top of the default configuration during the build.
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
.. they're needed for the RPC generation in glibc
on both Cygwin and MinGW-w64.
Neither are built on GNU/Linux and iconv is not
built on Darwin.
Two patches for gettext are needed, one so that
-O0 works and one so that static builds can be
made.
They can take a good while to build, so if not
needed for_host or for_build then they are not
built.
Signed-off-by: Ray Donnelly <mingw.android@gmail.com>
I've added the .config files to contrib/uClibc-defconfigs from buildroot
to use as default configs if they are not provided in the sample.
If a particular architecture really needs an option set, it should be
either updated in the manange_uClibc_config function in
scripts/build/libc/uClibc.sh or a custom ${uclibc_name}.config should be
added to the sample (usually via `ct-ng saveconfig`).
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
This commit removes blackfin support.
I'm open to re-adding blackfin after crosstool-1.23.0 is released, but
it is currently too difficult to port forward to newer versions of gcc
and uclibc.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
This is a weird artifact from when mips64 was first introduced to ct-ng
and was never removed from experimental.
If you have problems building a mips64 toolchain, please report on the
mailing list or on github issues.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
This change, as per #222, reduces the number of supported releases of
gcc to the latest branch releases.
I noticed while doing this work that gcc-4.5.4 was never added, so I
moved patches for gcc-4.5.3 to 4.5.4 and updated the
bfin-unknown-linux-uclibc example. Also, 120-siginfo.patch was fixed
upstream in the 4.5.4 release, so this patch is omitted.
I also bumped the avr sample to 4.9.3 from 4.9.2.
With the addition of gcc-5.x, the gcc release team now releases the
major.minor.0 versions, while updates to the branch are available in
svn/git. We'll address that when we get to issue #219. This change just
removes CC_GCC_5_1 and moves CC_GCC_5_2 to CC_GCC_5, and removes
CC_GCC_5_1_or_later and moves CC_GCC_5_2_or_later to CC_GCC_5_or_later.
This is the first of two part changes, as mentioned in #222.
This change is slated for release in 1.22.0. The next change will be
slated for 1.23.0, and will limit gcc versions to what is on
https://gcc.gnu.org under "Release Series and Status", which is
currently 4.9.3 and 5.2.0, although I will also support the previous
supported version. In this example that would be 4.8.5.
Last, but not least, this change also retires AVR32 support.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
Some older versions of configure (including the one in GMP 4.3.2)
interpret the $ECHO environment variable as the `echo' utility to
use. CT-NG sets the variable to `:' and exports it if V=0 or V=1
is supplied, breaking the samples using such configure. This currently
includes bfin-unknown-linux-uclibc and powerpc-unknown-linux-uclibc.
Also, correct the description of the V= variable - V=0 is *not* the
default; in fact, default does not correspond to any of the V=[012]
values.
Signed-off-by: Alexey Neyman <stilor@att.net>
The gold linker cannot currently be built in a static toolchain build.
This may get fixed in a future version of crosstool-NG.
Also, there is a bit of weirdness here. versions of binutils >= 2.21
have GOLD (BINUTILS_HAS_GOLD), but that doesn't mean it should be used.
For instance, if the architecture is not supported.
So with that, we create a new hidden option: BINUTILS_GOLD_SUPPORT
Which in turn depends on BINUTILS_GOLD_SUPPORTS_ARCH, BINUTILS_HAS_GOLD,
and not STATIC_TOOLCHAIN... then replace anything that previously
depended on BINUTILS_HAS_GOLD with our new BINUTILS_GOLD_SUPPORT option.
This closes#210
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
- New configurations:
- CC_GCC_TARGET_FINAL:
Use the default targets "all" and "install" for the final compiler for
bare metal.
- Adding parameter "build_step" to function do_gcc_core_backend:
do_gcc_core_backend is used for the core compiler and in case of bare metal
for the final compiler, too. To have better control over the parameters for
the final compiler "build_step" is used.
- Used for proper logging.
- Use CT_CC_GCC_CORE_EXTRA_CONFIG_ARRAY or CT_CC_GCC_EXTRA_CONFIG_ARRAY.
- If CT_CC_GCC_TARGET_FINAL is set and the final compiler is build then the
make targets for the final compiler are used ("all", "install").
Signed-off-by: Jasmin Jessich <jasmin@anw.at>
I forgot that the logs must stay small, and if they fail we'll grab the
last few hundered lines.
Note, the logs must stay smaller then 4M.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
This commit introduces a configure time option to let the build know
that this is going to be an automated build.
This forces the build to disable the progress bar, log tool warnings,
and force the log level to debug.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
After the Kconfig update the "option modules" setting must be set
on the MODULES config option to enable tristates again.
Signed-off-by: Philipp Kirchhofer <philipp@familie-kirchhofer.de>
independend configuration to enable LIBC_NEWLIB_CUSTOM.
All newlib versions >=2.0.0 does provide __cxa_atexit. To enable this function
in GCC, all versions >=2.0.0 does now select LIBC_PROVIDES_CXA_ATEXIT.
Signed-off-by: Jasmin Jessich <jasmin@anw.at>
glibc-2.17 and above no longer have external addons or ports.
So if we are => 2.17, don't even think about trying to mess with ports
or addons.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
* Add glibc 2.22
* Add a constraint on glibc-2.21 that depends on gcc-4.6 or greater.
See: https://sourceware.org/ml/libc-alpha/2015-02/msg00119.html
======================================================================
* The minimum GCC version that can be used to build this version of
the GNU C Library is GCC 4.6. Older GCC versions, and non-GNU
compilers, can still be used to compile programs using the GNU C
Library.
======================================================================
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
Support binutils 2.25.1 in configuration.
Note: The patches do apply, but I didn't check the resulting tools.
Signed-off-by: Jasmin Jessich <jasmin@anw.at>
Enable definition of "Use __cxa_atexit" for bare-metal systems, if the used
libc does provide such a function. The libc configuration have to select
LIBC_PROVIDES_CXA_ATEXIT.
Signed-off-by: Jasmin Jessich <jasmin@anw.at>
This commit updates to the latest longterm and stable kernel versions as
of July 12, 2015.
Signed-off-by: Cristoforo Cataldo <cristoforo.cataldo@gmail.com>
This commit adds support for the avr-libc C library.
According to the project page at http://www.nongnu.org/avr-libc , the
avr-libc package provides a subset of the standard C library for Atmel
AVR 8-bit RISC microcontrollers. In addition, the library provides the
basic startup code needed by most applications.
Support for this library in crosstool-ng is only enabled for the AVR
8-bit target.
The avr-libc manual and most distributions build the AVR 8-bit gcc
toolchain with the "avr" (non-canonical) target.
Some experimentation also led to the conclusion that other (canonical)
targets are not very well supported, so we force the "avr" target for
crosstool-ng as well.
The manual also recommends building avr-libc after the final gcc build.
To accomplish this with crosstool-ng, a new do_libc_post_cc step is
added, in which currently only avr-libc performs its build, and is a
no-op for the other libc options.
Signed-off-by: Erico Nunes <nunes.erico@gmail.com>
This commit adds support for the Atmel AVR 8-bit RISC architecture.
This is the first 8-bit architecture to be added to crosstool-ng so the
configuration options for 8-bit architectures are added here as well.
gcc has had support for AVR for quite a while, at least since the 4.3
series for the currently popular ATmega microcontroler series.
The AVR architecture only supports bare-metal toolchains.
gcc for the AVR 8-bit architecture, usually referred to as avr-gcc, is
commonly used in conjunction with the avr-libc library which provides
additional resources for the Atmel AVR 8-bit microcontrollers.
avr-gcc can also be found as a supported package in some recent Linux
distributions.
This commit also closes#66
Signed-off-by: Erico Nunes <nunes.erico@gmail.com>
Similarly to what we've just done to prevent both --with-arch and
--with-cpu, we do the same to prevent using both --with-cpu and
--with-tune at the same time, since --with-cpu should fully imply
the CPU to tune for (and gcc now errors out when both are specified.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Bryan Hundven <bryanhundven@gmail.com>
Normally, a specific CPU fully implies the architecture level. For
example, a cortec-a8 is forcibly an armv7, so spwecifying both is
redundant, and even dangerous (as incompatible values may be passed).
So far, gcc was pretty happy when both were specified at the same time,
and some time ago, it started being a warning, and only recently was it
turned into a hard error.
So, hide the architecture level prompt when a CPU has been specified.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
This functionality was provided so that crosstool-ng could have a
further set of patches considered experimental and unsupported.
Now that musl-libc support is making it's way upstream in gcc, I'm
removing this support and the experimental musl patches.
In later commits, backports from gcc upstream will be added to the
supported patch sets to support musl-libc.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
This commit updates the version knobs so that oldconfig does the right
thing when we bump versions.
Also, we update stable to 1.0.5 and experimental to 1.1.9.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
This change updates the config to support multiple compilers by moving
CC_.* to CC_GCC_.* to make room for other compilers.
We also update gen_in_frags.sh to check for a default cc.
Signed-off-by: Ray Donnelly <mingw.android@gmail.com>
Reviewed-by: Yann Diorcet <diorcetyann@gmail.com>
Reviewed-by: Bryan Hundven <bryanhundven@gmail.com>
As per: http://www.gnu.org/software/gdb/download/ANNOUNCEMENT
========================================================================
GDB 7.9.1 brings the following fixes and enhancements over GDB 7.9:
* PR build/18033 (C++ style comment used in gdb/iq2000-tdep.c and
gdb/compile/compile-*.c)
* PR build/18298 ("compile" command cannot find compiler if tools
configured with triplet instead of quadruplet)
* PR tui/18311 (Random SEGV when displaying registers in TUI mode)
* PR python/18299 (exception when registering a global pretty-printer
in verbose mode)
* PR python/18066 (argument "word" seems broken in Command.complete
(text, word))
* PR pascal/17815 (Fix pascal behavior for class fields with
* testcase)
* PR python/18285 (ptype expr-with-xmethod causes SEGV)
========================================================================
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
While we do want users to be able to use the mingw from git, being under
the experimental umbrella makes it more obvious that this should not be
used as a production toolchain.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
"The Graphite framework for loop optimizations no longer requires the
CLooG library, only ISL version 0.14 (recommended) or 0.12.2. The
installation manual contains more information about requirements to
build GCC."
This change helps to avoid version badness.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
This change needs another change from pull request #81, but it's kind of
a chicken/egg scenario. The 'select's in CC_GCC_5_1 need to be
refactored a bit, and would be easier to test if gcc-5.1.0 was commited.
Most of the refactoring will happen with CC_GCC_HAS_GRAPHITE.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
In commit cd47c091ba
I had forgot to also remove the config/libc/eglibc.in.
This commit removes it.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
There are other languages which work with bare metal compilers.
As an example crosstool-ng is recommended to build D/GDC bare metal
compilers.
Signed-off-by: Johannes Pfau <johannespfau@gmail.com>
This commit updates to the latest longterm and stable kernel versions as
of March 15, 2015.
Signed-off-by: Cristoforo Cataldo <cristoforo.cataldo@gmail.com>
This commit updates to the latest longterm and stable kernel versions as
of February 18, 2015.
Signed-off-by: Cristoforo Cataldo <cristoforo.cataldo@gmail.com>
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 commit updates to the latest longterm and stable kernel versions as
of January 16, 2015 and adds also 3.18 version.
Signed-off-by: Cristoforo Cataldo <cristoforo.cataldo@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>
Can safely skip the core pass-1 for normal baremetal builds,
but when building a canadian baremetal, the repair_cc
functionality (GCC_FOR_TARGET) in gcc.sh will force the
core pass-2 to attempt to build gcc and libgcc without a
${CT_TARGET}-gcc existing, causing a failure on
${CT_TARGET}-gcc -dumpspecs > tmp-specs
Signed-off-by: David Holsgrove <david.holsgrove@xilinx.com>
This commit updates to the latest longterm and stable kernel versions as of
December 10, 2014.
Signed-off-by: James Byrne <james.byrne@origamienergy.com>
As per the glibc release notes for 2.20:
--------------------------------------------------------------------------------
All supported architectures now use the main glibc sysdeps directory
instead of some being in a separate "ports" directory (which was
distributed separately before glibc 2.17).
--------------------------------------------------------------------------------
There isn't a ports directory anymore. So disable using and forcing it.
closes#7 on crosstool-ng github
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
I messed up the previous commit.
I only updated half the config file, and the latest 4.8 is 2014.08.
🤦
Signed-off-by: Bryan Hundven <bryanhundven@gmail.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 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>
This change removes 1.0.3 and 1.1.3 and linker regession patches for
those versions.
We add 1.0.4, and a patch needed for gcc-4.9.x which defines
`max_align_t'.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
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>
There is no need to differentiate the win32 threads case, since we
can cosider them to be the native implementation on Windows.
Besides, with the previous patch, nothing uses it anymore.
So, just remove it.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc Bryan Hundven <bryanhundven@gmail.com>
This will help add new implementations, such as the one in musl.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Bryan Hundven <bryanhundven@gmail.com>
Use a more coherent naming for the options. This will help commonalise
the native case (e.g. NPTL on Linux, win32 on Windows), and add alternate
implementations (e.g. musl.)
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Bryan Hundven <bryanhundven@gmail.com>
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>
