Commit 1a25115a18 deleted non-GCC related
files, including the patch for uClibc to compile with Linux kernels after
3.4.
uClibc 0.9.30 patches are not restored by this change (0.9.30 is broken
with recent kernels for multiple other breakages in addition to that; if
not retired, it needs to be fixed properly).
Signed-off-by: Alexey Neyman <stilor@att.net>
Some architectures, like arc and blackfin set CROSS_COMPILE to a default
if it is not set on the command-line.
Since we are building the cross-compiler, we need to ALWAYS set
CROSS_COMPILE, since building/checking headers is done after the GCC
PASS1 step.
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>
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>
If the build is aborted before the working directory is created,
there's also an induced error message about inability to create
a 'backtrace' file. But in that case, there is no subshells executing
yet.
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>
'ct-ng show-config' will prepend host for canadian builds; otherwise,
the name is different from the name used to configure the build
(and indistinguishable from a simple cross).
Signed-off-by: Alexey Neyman <stilor@att.net>
Provides a simpler alternative to editing config to enable
CT_ONLY_DOWNLOAD, doing ct-ng build and then restoring .config.
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>
Having *.la in the installation directory breaks ltrace: in ltrace,
libtool somehow considers libsupc++ to be an "accessory library" and
does not add -lsupc++ to the link flags. Neither Ubuntu, nor RedHat
include *.la files into their packages for libstdc++.
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>
