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 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>
Instead, continue until the end and provide a summary (PASS/XFAIL/FAIL)
at the end. If there are any FAILs, exit with code 1.
Signed-off-by: Alexey Neyman <stilor@att.net>
First, build cross samples (indicated by lack of comma in their names);
then, build canadian cross samples (and, when they are supported,
cross-native). While building canadian cross, set up the path to the
build-to-host cross if it was built previously.
Signed-off-by: Alexey Neyman <stilor@att.net>
'make oldconfig' results in asking the user about options not explicitly
set in the defconfig. Instead of copying, run 'conf --defconfig', as in
the normal sample's build sequence. Also, invoke 'conf --oldconfig'
directly, with a -s option, to avoid spamming with useless
"configuration written to .config" messages.
Signed-off-by: Alexey Neyman <stilor@att.net>
With current name, 'make saveconfig' is broken for this sample. Also, it
is confusing to have a sample named 'nios2-elf-mingw32' while show-tuple
refers to it as 'nios2-spico-elf' and saveconfig attempts to save it
into 'i686-w64-mingw32,nios2-spico-elf'.
Signed-off-by: Alexey Neyman <stilor@att.net>
Building cross-gdb in canadian cross requires expat/ncurses for the
host. Currently, 300-gdb.sh only builds expat/ncurses for the target
(for native-gdb). For cross-gdb on regular cross (build==host), expat
and ncurses are expected to be provided by the host.
There are two approaches possible:
- If building for canadian cross, build expat/ncurses for cross-gdb
just as the native-gdb does.
- Promote expat/ncurses to first class citizens and build them as
companion libs during the build of the build-to-host toolchain.
I am leaning towards the latter approach - it would also allow to
specify the versions for expat/ncurses rather than have them hardcoded
in 300-gdb.sh - but would appreciate feedback.
Signed-off-by: Alexey Neyman <stilor@att.net>
Error message:
[EXTRA] Preparing working directories
[ERROR] Missing: 'i586-mingw32msvc-ar' or 'i586-mingw32msvc-ar' or 'ar': either needed!
Signed-off-by: Alexey Neyman <stilor@att.net>
The issue with this sample is that the sh4-* targets in GCC do not
implement __builtin_trap() function. Starting with release 5.1,
GCC inserts abort() calls where NULL pointers are dereferenced. The
elf/dl-conflict.c in glibc is one such place: it calls elf_machine_rela
with NULL `sym' pointer. This causes an undefined `abort' symbol to
appear in the object file and as a result, pulls in some files during
the linking of the dynamic loader that are not supposed to. Eventually,
it results in link error due to multiple definitions of _itoa and some
other symbols.
The right fix would be to implement __builtin_trap() for sh4 in GCC.
A workaround would be adding -fno-delete-null-pointer-checks to
CFLAGS-dl-conflict.c in elf/Makefile. Until either of these happens,
though, pin the GCC version to 4.9.3 - the last that did not generate
`abort' calls. Note that the version where GCC started to generate
`abort' calls is apparently different for different architectures;
the issue in [1] was reported against GCC 4.9.
References:
[1] https://www.sourceware.org/ml/libc-alpha/2014-10/msg00807.html
(similar issue on HP-PA which was resolved by implementing
__builtin_trap)
Options were renamed. However, matching current option names result
in a compile error for strfmon_l.o in glibc: GCC 4.6 detects an
unitialized variable in its own va_arg() implementation. Likely,
an older GLIBC was used when this sample was submitted - which did
not provide -Werror in CFLAGS.
Thus, use most recent GCC (5.2.0) and revert GLIBC_FORCE_UNWIND to
its default value, 'y' (as forced unwind is required with this version).
- Incompatible ISL/CLooG were requested by config after newer releases
of both were brought in.
- Consistency with other samples: save tarballs (which will avoid
downloading them each time from Travis), extra logging.
This should ideally be upstreamed to uclibc maintainers, but with the
last release more than 3 years ago, I wouldn't hold my breath for a
fix being released any time soon.
As of right now, ltrace fails to build. To get CI happy, lets just
disable it!
When we fix ltrace, just revert this change.
This is also in reference to bug #115
Signed-off-by: Bryan Hundven <bryanhundven@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>
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>
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>
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>
Fixing this sample proved to be, well, challenging.
Mark it broken so it does not stop the release.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Bryan Hundven <bryanhundven@gmail.com>
Removed the arm-davinci sample, it does not bring much more
that the other samples.
Add an ARM uClibc EABIhf sample.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
