* 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>
Configure for for core GCC did not use Core gcc extra config.
Use now config variable CT_CC_GCC_CORE_EXTRA_CONFIG_ARRAY.
Signed-off-by: Jasmin Jessich <jasmin@anw.at>
This changeset fixes an 'incomplete type struct siginfo' error when
attempting to build gcc-4.5.3 for mipsel.
Signed-off-by: Ben Gardiner <ben.l.gardiner@gmail.com>
.. and set CT_TARGET_VENDOR to w64. Otherwise config.gcc doesn't
pickup the right files for include_next (and probably many other
things go wrong too).
w64 has been the correct vendor for absolutely ages now on all
distributions that provide MinGW-w64 cross compilers.
Signed-off-by: Ray Donnelly <mingw.android@gmail.com>
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>
C++ support is enabled in most samples existing in crosstool-ng and is also
supported by AVR.
As pointed out in pull request #124 in the crosstool-ng github, Arduino based
projects willing to use this toolchain will require C++ support.
Signed-off-by: Erico Nunes <nunes.erico@gmail.com>
avr-libc doesn't have write permissions in these by default in the 1.8.1
tar release, this caused an error during build with
CT_OVERIDE_CONFIG_GUESS_SUB enabled.
chmod u+w them before overriding to avoid an this error.
Signed-off-by: Erico Nunes <nunes.erico@gmail.com>
Distribution avr toolchains commonly add a patch to binutils' size to
enable a custom "-C" option that shows AVR memory usage.
This patch is specific to the AVR architecture.
In order to make the crosstool-ng AVR toolchain compatible with existing
distribution toolchains, this patch is necessary.
Signed-off-by: Erico Nunes <nunes.erico@gmail.com>
Add support for applying arch-specific patches found in
"patches/${pkgname}/${version}/${CT_ARCH}".
This is needed for applying a popular binutils patch specific for the
AVR architecture but which isn't isolated for AVR in binutils' code.
In this case, applying it for every architecture would end up bloating
binutils' "size" options with AVR specifics.
This feels like a bit of a hack but it is easy enough to support with
current crosstool-ng infrastructure, seems like worth it for this case.
Signed-off-by: Erico Nunes <nunes.erico@gmail.com>
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.
Some patches are required in avr-libc for a toolchain with gcc 5.x to
work. These patches are still not part of any avr-libc release version,
so the config sample currently forces 4.9.x to avoid requiring to clone
avr-libc trunk.
References:
https://savannah.nongnu.org/bugs/?44574https://gcc.gnu.org/gcc-5/changes.html
Signed-off-by: Erico Nunes <nunes.erico@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>
Due to patch 0e45cdf, the VERSION string has changed. And so, the the sub
directory names has changed too:
From 'ct-ng.1.21.0' to 'ct-ng.crosstool-ng-1.21.0-xx-yyyyyyy'
This patch rename the sub directory to: 'crosstool-ng-1.21.0-xx-yyyyyyy'
Signed-off-by: Jean-Marie Lemetayer <jeanmarie.lemetayer@gmail.com>
With newer version of the patch program, it no longer follows symlinks:
========================================================================
a/patch-2.7.4-x86_64-1.txz: Upgraded.
Patch no longer follows symbolic links to input and output files.
This
ensures that symbolic links created by git-style patches cannot cause
patch to write outside the working directory.
For more information, see:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-1196
(* Security fix *)
========================================================================
This copies patches/glibc/2.20 to patches/glibc/linaro-2.20-2014.11.
This change also closes#51
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
The missing definition of $tmpdir caused it to default to /tmp, which
may cause problems when testcases generate temporary files in the
current directory ($TOPDIR) and then try to access them at $tmpdir.
Errors such as the following were reported in test-suite runs for both
arm and powerpc toolchains due to $tmpdir pointing to /tmp and files
being generated in $TOPDIR:
error: could not open dump file '/tmp/dump1/dump-noaddr.c.011t.cfg':
No such file or directory
FAIL: gcc.c-torture/unsorted/dump-noaddr.c, -O0 -dumpbase
dump1/dump-noaddr.c -DMASK=1 -x c --param ggc-min-heapsize=1
-fdump-ipa-all -fdump-rtl-all -fdump-tree-all -fdump-noaddr
FAIL: gcc.dg/tree-prof/ic-misattribution-1.c execution:
file ic-misattribution-1.gcda does not exist, -fprofile-generate
-D_PROFILE_GENERATE
Signed-off-by: Erico Nunes <erico.nunes@datacom.ind.br>
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 change removes the static .version file, and moves to using the git
tag as the version number, the change number if the current commit is
newer then the latest tag, and '-dirty' if there are changes to the git
repository since the last commit that are uncommitted.
This helps us in the troubleshooting process to identify if the user is:
* using a released version (i.e.: 1.21.0)
* using a clone from git (i.e.: 1.21.0-29-13e14f)
* using a clone from git with local uncommitted changes (i.e.: 1.21.0-29-13e14f-dirty)
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
