The following versions were marked obsolete in crosstool-ng-1.24.0,
remove them.
- mingw-w64-v2.0.10
- mingw-w64-v3.0.0
- mingw-w64-v3.1.0
- mingw-w64-v3.2.0
- mingw-w64-v3.3.0
Signed-off-by: Chris Packham <judge.packham@gmail.com>
The following versions were marked obsolete in crosstool-ng-1.24.0,
remove them.
- make-3.81
- make-4.0
- make-4.1
Signed-off-by: Chris Packham <judge.packham@gmail.com>
The following versions were marked obsolete in crosstool-ng-1.24.0,
remove them.
- libiconv-1.14
Signed-off-by: Chris Packham <judge.packham@gmail.com>
The following versions were marked obsolete in crosstool-ng-1.24.0,
remove them.
- isl-0.11.2
- isl-0.12.2
- isl-0.14.1
Signed-off-by: Chris Packham <judge.packham@gmail.com>
The following versions were marked obsolete in crosstool-ng-1.24.0,
remove them.
- gmp-4.3.2
- gmp-5.0.5
- gmp-5.1.3
- gmp-6.0.0a
Signed-off-by: Chris Packham <judge.packham@gmail.com>
The following versions were marked obsolete in crosstool-ng-1.24.0,
remove them.
- gettext-0.19.7
Signed-off-by: Chris Packham <judge.packham@gmail.com>
The following versions were marked obsolete in crosstool-ng-1.24.0,
remove them.
- gcc-linaro-4.8-2015.06
- gcc-4.8.5
Signed-off-by: Chris Packham <judge.packham@gmail.com>
The following versions were marked obsolete in crosstool-ng-1.24.0,
remove them.
- binutils-linaro-2.23.2-2013.10-4
- binutils-linaro-2.24.0-2014.11-2
- binutils-linaro-2.25.0-2015.01-2
- binutils-2.23.2
- binutils-2.24
- binutils-2.25.1
Adjust the milestones now that the old versions have been removed.
Signed-off-by: Chris Packham <judge.packham@gmail.com>
The following versions were marked obsolete in crosstool-ng-1.24.0,
remove them.
- automake-1.11.6
- automake-1.14.1
Signed-off-by: Chris Packham <judge.packham@gmail.com>
The following versions were marked obsolete in crosstool-ng-1.24.0,
remove them.
- android-ndk-r10e
- android-ndk-r11c
- android-ndk-r12b
- android-ndk-r13b
Signed-off-by: Chris Packham <judge.packham@gmail.com>
Now that the oldest supported version of gdb is 7.11.1 we can make some
parts of the build unconditional and remove the associated config vars.
Signed-off-by: Chris Packham <judge.packham@gmail.com>
Drop the uclibc-no-gettimeofday-clobber patch as it no longer applies.
The arc patches are all upstream.
Signed-off-by: Chris Packham <judge.packham@gmail.com>
Mark all of the 7.x series obsolete, retain only the latest 8.x release.
These will be removed after the next release.
Signed-off-by: Chris Packham <judge.packham@gmail.com>
Back in the day gdbserver was treated as a subproject of GDB and
even was located in "gdb/gdbserver" and so to build gdbserver we had
to go into "gdb/gdbserver" and there run configure. That way full GDB
was out of the picture.
Now starting from GDB 10.1 where gdbserver was promoted to the top-level
we're supposed to run top-level's configure script for all the tools
provided by the unified binutils-gdb tree.
That said if we only want to build gdbserver (and that's what we
want since we build one tool at a build step) we have to be explicit:
----------------->8----------------
--enable-gdbserver --disable--gdb
----------------->8----------------
Ah, and so far we used to build full native GDB when only wanted gdbserver
if it was GDB v10.x ;)
Ironically full native/target GDB also enabled gdbserver by default so
we need to also disable it explicitly with "--disable-gdbserver".
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Since we have curses built for target anyway now, why don't allow
users to use very convenient pseudo-GUI operating mode?
And while at it, there's no use of TUI in naturally headless gdbserver.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
With this we may finally build Windows and "native" toolchains
if host tools are also GCC11 based. For example:
1. You build cross toolchain with all the recent components by CT-NG
2. You build cross-canadian toolchain for Windows or ARC, ARMm whatever board
See upstream bug report [1] for more details.
Basically when we do cross-canadian build with
use of the same GCC11 as a "host" compiler we're seeing
an error like that:
------------------->8-------------------
mingw-w64-cross/gcc/x86_64-w64-mingw32/libstdc++-v3/include/fenv.h:58:11: error: 'fenv_t' has not been declared in '::'
58 | using ::fenv_t;
------------------->8-------------------
This is a solution proposed by Yujie Yang in [2]
Note, though it's not the final fix merged upstream, that's just
an attempt to fix this by casual GCC users. There's a hope it
will be fixed anyways a bit later, maybe by the time of GCC 11.3...
[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017
[2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017#c20
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Here we add a couple of fixes and improvements for ARC processors.
All except 1 patch are already in the upstream "master" branch
and will be an essential part of GCC 11.x whenever it gets released.
The most important are first 4 patches (0005-0008) which introduce
support of full native GDB support in Linux on ARC.
And the rests are tiny, yet useful improvements.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
This fixes a defect introduced in 25162c7. The "uint" type has not
been explicitly defined here on mingw, causing compilation to fail.
Signed-off-by: Artem Panfilov <artemp@synopsys.com>
"--with-host-libstdcxx" option was removed in GCC 6.x, see [1] because of [2].
So it makes no sense to use it with later GCC versions.
Frankly I don't like that implementation with yet another set of "if XXX",
but since we still support GCC down to 4.8.5 what else we may do?
Well, technically we may keep using things as they are now,
because surprisingly GCC's configure script doesn't mind accepting
meaningless options, but as a person who's looking at differences between
various builds and drill-down to peculiarities of various config
options, I'd prefer to not pollute configure with garbage.
But for all the rest... well, it works now and maybe nodody else cares.
[1] https://gcc.gnu.org/git/?p=gcc.git&a=commit;h=5dc85f7ec719a79ecfbcdd8563b07e5f0f365e65
[2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67092
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
GCC 11+ requires compiler being used to support C++11 standard [1].
And while GCC starting from 6.x has C++11 support enabled by default [2],
older versions need to be forced to implement it with "-std=gnu++11" and luckily
GCC's build-system takes care of that:
1. For ${host} compiler - [1]
2. For ${build} compiler - [3, 4]
In a nutshell the configure script tries a couple of options and the one which
helps to build a test source gets appended to CXX (not CXXFLAGS!),
so on say CentOS 7.x with GCC 4.8.5 during cross-compilation of GCC
CXX="x86_64-build_pc-linux-gnu-g++ -std=gnu++11". And all is good.
But in case of canadian cross due to [5] we for some reason* force set
CXX_FOR_BUILD with just a compiler name, effectively overriding all the
magic done by GCC's internals described above.
This leads to a compilation failures like that:
------------------------------------->8----------------------------------
[ALL ] In file included from /usr/include/c++/4.8.2/type_traits:35:0,
[ALL ] from .../HOST-x86_64-apple-darwin14/arc-gcc11-elf/src/gcc/gcc/system.h:244,
[ALL ] from .../HOST-x86_64-apple-darwin14/arc-gcc11-elf/src/gcc/gcc/gengtype.c:26:
[ERROR] /usr/include/c++/4.8.2/bits/c++0x_warning.h:32:2: error: #error This file requires compiler and library support for the ISO C++ 2011 standard. This support is currently experimental, and must be enabled with the -std=c++11 or -std=gnu++11 compiler options.
[ALL ] #error This file requires compiler and library support for the ^
------------------------------------->8----------------------------------
* my guess that [5] was done because back in the day indeed we used to have
"--build=${CT_BUILD} --host=${CT_HOST}" in do_cc_core(). But now after [6]
this is no longer necessary as we use "--build=${CT_BUILD} --host=${CT_BUILD}"
and all is safe and clean. So yet another old quirk goes away - hooray!
[1] https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=5329b59a2e13dabbe2038af0fe2e3cf5fc7f98ed
[2] https://gcc.gnu.org/gcc-6/changes.html
[3] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96612
[4] https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=7ffcf5d61174dda1f39a623e15f7e5d6b98bbafc
[5] 9c6c090d7b
[6] 08161250ed
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
GCC can support using zstd compression for LTO object files. By default
GCC's configure will enable this if libzstd is installed on the machine
building the toolchain. This may be undesirable if the toolchain is to
be used on a different machine. Add an option to control zstd usage and
set the default to the same as the current behaviour (i.e. auto).
Fixes#1579
Signed-off-by: Chris Packham <judge.packham@gmail.com>
