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>
