${CT_PREFIX_DIR} may contain relative paths (e.g.
"${CT_TOP_DIR}/../x-tools/${CT_TARGET}"). Code added in commit d83a0036
("Add symlinks from the libraries' original location to the new one.")
didn't cope well with this. As we're already calculating
${cannon_prefix} make use of it when adding the symlinks. This avoids
any issues with ${CT_PREFIX_DIR}.
Fixes#1807
Signed-off-by: Chris Packham <judge.packham@gmail.com>
This warning is designed to catch likely vulnerabilities in code run
under memory protection -- allowing execution from memory which is
writable. However, embedded arm systems frequently require placing code
in RAM, for performance or functionality reasons. Disable the warning
that recent versions of binutils has added.
Signed-off-by: Keith Packard <keithp@keithp.com>
Add sample config for target loongarch64-unknown-linux-gnu.
Currently, it fails to build on macOS due to flex/bison incompatibility.
Signed-off-by: Jiajie Chen <c@jia.je>
This commit adds architecture support for LoongArch.
The toolchain currently only supports the 64-bit target
loongarch64-unknown-linux-gnu.
It has been tested to build with GCC 12.1, GDB 12.1, Glibc 2.36, Linux
5.19 and Binutils 2.39 as of Aug 2022.
Signed-off-by: Jiajie Chen <c@jia.je>
https://sourceware.org/pipermail/binutils/2022-August/122246.html
Add binutils 2.39 and regenerate patches.
0008-binutils-2.38-vs.-ppc32-linux-kernel.patch is dropped as it has
been applied upstream. Add a milestone for 2.39 which will be handy for
Loongarch.
Binutils now requires bison >= 3.0.4 to build gprofng for x86/aarch64 so
we build our own bison when the host bison does not meet that
requirement (which appears to be the case on macOS).
Signed-off-by: Chris Packham <judge.packham@gmail.com>
Add 5.19
Bump 5.18.4 -> 5.18.15
Bump 5.15.47 -> 5.15.58
Bump 5.10.122 -> 5.10.134
Bump 5.4.198 -> 5.4.208
Bump 4.14.283 -> 4.14.290
Bump 4.9.318 -> 4.9.325
Add a milestone for 5.19 as this adds support for the loongarch
CPU architecture.
Signed-off-by: Chris Packham <judge.packham@gmail.com>
https://sourceware.org/pipermail/libc-announce/2022/000034.html
Add the new version. Regenerate the patches and remove the one that had
been applied upstream. Add a milestone for 2.36 as this version
introduces support for the loongarch CPU architecture.
Fixes#1795
Signed-off-by: Chris Packham <judge.packham@gmail.com>
It appears that noyywrap is actually what is needed for kconfig.
Particularly on arclinux where the default flex installation does not
provide the yywrap function.
Fixes#1790
Fixes 015d039e ("AC_PROG_LEX set to yywrap")
Signed-off-by: Chris Packham <judge.packham@gmail.com>
Add x86_64-w64-mingw32 to the list of samples we use to fetch sources.
This should pick up the mingw related tarballs so the build steps that
follow don't have to.
Signed-off-by: Chris Packham <judge.packham@gmail.com>
https://gcc.gnu.org/pipermail/gcc-announce/2022/000173.html
Add GCC 10.4.0 and regenerate the ct-ng patches. The
powerpc-Fix-asm-machine-directive-for-some-CPUs patch is dropped as the
change was applied upstream (and subsequently refactored).
Closes#1777
Signed-off-by: Chris Packham <judge.packham@gmail.com>
libsanitizer is only supported on selected architectures. Add
ARCH_SUPPORTS_LIBSANITIZER and have architectures select this option
based on the list of supported configurations from GCC's
libsanitizer/configure.tgt. Support for mips64 was added in GCC12 so
this is an additional condition for the mips architecture.
Fixes#1733
Signed-off-by: Chris Packham <judge.packham@gmail.com>
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>
CT_CC_{CORE_}SYSROOT_ARG is being used both as an array and string. Switch everything
to be used as an array for consistency.
Signed-off-by: Justin Chen <justinpopo6@gmail.com>
Configuring the newlib with "--enable-newlib-nano-formatted-io" and
"--enable-newlib-io-pos-args" would cause built GCC cannot compile some
IO functions like "std::cout".
And I added additional notes at Nano Formatted I/O config.
Signed-off-by: Chen Tao <t.clydechen@gmail.com>
fix conflict options when compiling multilibs on ARM based architecture.
"--with-arch", "--with-cpu", "--with-fpu", "--with-float", and
"--with-mode" should not be configured with "--with-multilib-list=list"
when configuring multilibs.
Signed-off-by: Chen Tao <t.clydechen@gmail.com>
Tabs or spaces... I believe the policy on ct-ng is spaces for shell
scripts. So update bootstrap to stick to 4 space indent.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
This commit restore the support for the following products
in Oracle Linux 7.9:
Binutils 2.27-44.base.0.400
GCC 4.8.5-44.0.5
glibc 2.17-317.0.3
UEK5/u4 4.14.35-2025.400.8
Sample configurations were updated to use such versions,
and be compiled in host machine using recent GCC versions.
Signed-off-by: Guillermo E. Martinez <guillermo.e.martinez@oracle.com>
After building the cross toolchain and compile a simple C program,
objdump reports debug information even though -g modifier was not
used. These debug segments are in glibc library and CRT files. So
a new config entry: CT_GLIBC_ENABLE_DEBUG was added to control when
we want to add debug information to glibc, by default is enabled.
Signed-off-by: Guillermo E. Martinez <guillermo.e.martinez@oracle.com>
Add TARBALL_RESULT option that will produce a tarball of the final
toolchain to make it easier to deploy the toolchain to other machines.
The implementation uses `find | sort` instead of `tar --sort` because
this was introduced in GNU Tar v1.28, which is not available in some LTS
Linux distributions. This is a variation of the command recommended
here: https://wiki.debian.org/ReproducibleBuilds/FileOrderInTarballsCloses#1262
Signed-off-by: Chris Packham <judge.packham@gmail.com>
Make the requirement for bison harder (but not strict). The system bison
will be used to build kconf. If the system bison is not GNU bison 2.7 or
later crosstool-ng will build GNU bison as a companion tool if necessary
(for glibc 2.29 or newer).
Fixes#1621
Signed-off-by: Chris Packham <judge.packham@gmail.com>
When core gcc older than v5 is compiled it shows the error message:
Build failed in step 'Installing core C gcc compiler'
called in step '(top-level)'
Error happened in: CT_DoExecLog[scripts/functions@376]
called from: do_gcc_core_backend[scripts/build/cc/gcc.sh@627]
called from: do_cc_core[scripts/build/cc/gcc.sh@210]
called from: main[scripts/crosstool-NG.sh@697]
configure: error: in
`.../build/build-cc-gcc-core/fixincludes':
configure: error: C compiler cannot create executables
This patch disable `all-build-libcpp' target when core gcc
older than v5 is configured.
Signed-off-by: Guillermo E. Martinez <guillermo.e.martinez@oracle.com>
We don't currently bundle zstd so when performing a canadian build we
need to tell GCC not to enable zstd support for lto otherwise it might
decide to enable it based on the package being installed on the build
machine.
Fixes#1718
Signed-off-by: Chris Packham <judge.packham@gmail.com>
When GMP is being "cross" compiled for the same architecture (i.e. build
== host) it does not pick the right compiler. Set CC_FOR_BUILD and
CPP_FOR_BUILD to override the default compiler.
Fixes#1328
Signed-off-by: Chris Packham <judge.packham@gmail.com>
