This reverts commit 1b6ad7cd48. As it
turns out libsanitizer isn't supported on mips64 with GCC11 or older
(there is support in GCC12). The bug is actually the fact that ct-ng
allows configuring libsanitizer for architectures that don't support it.
Signed-off-by: Chris Packham <judge.packham@gmail.com>
Extend the fix from commit 6b465e15 ("Remove m1 from multilibs for GCC11
on SH arch.") to cover GCC 12 and future releases.
Remove the patch that was added to solve the same problem.
Signed-off-by: Chris Packham <judge.packham@gmail.com>
For some reason GCC 12 ends up hitting the _MIPS_SIM_NABI32 case for
Linux's arch/mips/include/uapi/asm/stat.h when building libsanitizer.
This is basically the opposite of the problem from
commit 1b6ad7cd ("gcc: Bring in fix for libsanitizer on mips64").
Dropping the patch resolves the issue for GCC 12.
Fixes#1741
Signed-off-by: Chris Packham <judge.packham@gmail.com>
Add GCC 12.1 https://gcc.gnu.org/gcc-12/
The following patches from GCC 11.3.0 are no longer needed:
- 0005-arc-Update-ZOL-pattern.patch
- 0006-arc-Update-u-maddhisi4-patterns.patch
- 0007-arc-Fix-maddhisi-patterns.patch
- 0008-Darwin-aarch64-Initial-support-for-the-self-host-dri.patch
- 0009-libstdc-Check-for-TLS-support-on-mingw-cross-compile.patch
One new patch is needed to avoid issues building sh-unknown-elf:
- 0006-sh-Avoid-mb-m1-multilib-combination.patch
It is also necessary to build all-build-libcpp. This target exists as
far back as GCC 6 so has been done unconditionally.
Signed-off-by: Chris Packham <judge.packham@gmail.com>
The kernel's struct stat is 104 bytes when compiling for
_MIPS_SIM_ABI64. Set struct_kernel_stat_sz to match.
Fixes#1733
Signed-off-by: Chris Packham <judge.packham@gmail.com>
This refreshes the line numbers, removes any fuzz (which would make any
future forward ports easier) and standardizes the patch/file headers
(which makes them easier to read).
Signed-off-by: Alexey Neyman <stilor@att.net>
... and the code dependent on them, after the latest wave of obsolete
package removals. This concludes the glorious history of the original
uClibc (non-NG) with lots of kludges removed.
There was a choice here, whether to call the resulting libc "uClibc" or
"uClibc-ng". I opted in favor of giving uClibc-ng the recognition it
deserves, although it had some ripple effect in the ct-ng code.
Signed-off-by: Alexey Neyman <stilor@att.net>
GCC 4.8 and its prerequisites have been removed by 04dce680, 41d4583a
and e4221734; as a result, 4.8-based version of gcc-oracle became
unbuildable (no valid versions for the prerequisites).
Update the samples to use 4.9.4; which however fails to build on a modern
host GCC. Build fix backported to gcc-4.9 and gcc-5 versions.
Fix binutils-oracle build with host GCC11.
Signed-off-by: Alexey Neyman <stilor@att.net>
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>
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>
Some of the installed libstdc++ header files use '#include_next' to
work around toolchain oddities that might cause loops in the
compiler. However, these also cause mistakes in locating header files
when there are multiple C libraries installed as '#include_next' often
ends up finding default C library header files.
It doesn't seem like this patch could be accepted upstream; there's a
long discussion about the use of include_next in these headers which I
cannot fully understand.
Signed-off-by: Keith Packard <keithp@keithp.com>
This commit adds the missing gcc milestones 9 and 10, so that the
helper symbols `GCC_9_or_later` and `GCC_10_or_later` can be used.
Signed-off-by: Stephanos Ioannidis <root@stephanos.io>
This change replicates what GLIBC 2.23 has in the string/rawmemchr.c:
// #if __GNUC_PREREQ (11, 0)
// /* Likewise GCC 11, with a different warning option. */
// DIAG_IGNORE_NEEDS_COMMENT (11, "-Wstringop-overread");
// #endif
With -Werror multiple platforms failing on the string/rawmemchr.c:40 line.
Signed-off-by: Nik Konyuchenko <spaun2002mobile@gmail.com>
This adds another mode to do_gcc_core_backend that builds libstdc++
against an alternate libc implementation.
Signed-off-by: Keith Packard <keithp@keithp.com>
If we are targetting an aarch64-none-elf toolchain we end up running
into a build issue in gcc/config/aarch64/driver-aarch64.c. This is
fixed in upstream gcc so just backport the patch to gcc-10.2.0
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Pull in a change from upstream GCC and one from the gcc-darwin-arm64
repo that gets an initial cross compiler building on ARM based Mac.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
When building aarch64-unknown-linux-gnu on MacOS X, aarch64-builtins.c
files doesn't build by default with clang on MacOS X. We need to pass
-std=gnu++11 when building the file for things to work with clang.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Forward ported patches from GCC 9.x, refreshed to match current sources.
Patch 0010-crystax.patch did not apply clean and had minor adjustments
to fit new GCC 10.2.0 release.
Signed-off-by: Hans-Christian Noren Egtvedt <hegtvedt@cisco.com>
Forward ported patches from GCC 9.2.0 to 9.3.0, refreshed to match
current sources.
Patch 0010-crystax.patch did not apply clean and had minor adjustments
to fit new GCC 9.3.0 release.
Signed-off-by: Hans-Christian Noren Egtvedt <hegtvedt@cisco.com>
-- c6x: Add support for c6x product families to pass on to uClibC-ng
-- c6x: Fix multilib support
-- c6x: Add patch fix internal instruction error (GCC 57295)
Signed-off-by: Dan Tejada <dan.tejada@cantada.com>
When GCC was updated to 8.4.0 the patches were moved incorrectly. Fix
this now so that they will be picked up.
Fixes: commit 31ca84ac ("Update to gcc 8.4.0")
Signed-off-by: Chris Packham <judge.packham@gmail.com>
bison, elf2flt, gcc, isl, linux, mingw-w64, strace.
Adjust checksum ordering in uclibc-ng so that it matches what the script
generates.
Signed-off-by: Alexey Neyman <stilor@att.net>
Forward ported patches from GCC 8.3.0 to 9.2.0, refreshed to match
current sources.
In patch 0012-crystax.patch, removed changing sysv4.h header file for
rs6000, since it no longer defines LINK_EH_SPEC.
Removed the following patches because they are part of upstream:
- 0018-ARC-Add-multilib-support-for-linux-targets.patch
- 0020-ARM-fix-cmse.patch
- 0021-arm-Make-arm_cmse.h-C99-compatible.patch
- 0022-ARC-Update-fma-expansions.patch
Renamed 0019-isl-0.20.patch => 0018-isl-0.20.patch.
Signed-off-by: Hans-Christian Noren Egtvedt <hegtvedt@cisco.com>
Had to update the following patches so they'd apply:
0006-libgfortran-missing-include.patch
0010-crystax.patch
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
