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>
Use `depends on` conditions to enable/disable building glibc with
-Werror. Using `depends on` instead of `default if` means that when the
GCC/GLIBC selection changes GLIBC_ENABLE_WERROR will automatically
become n.
Fixes#1729, fixes#1712
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>
This commit adds support for the following Oracle products, in order
to target Oracle Linux 8.6:
Binutils 2.30-113.0.1
GCC 8.5.0-10.0.2
glibc 2.28-189.1.0.1
UEK5/u4 4.14.35-2025.400.8
Sample configuration files are provides for the following triplets:
aarch64-ol8u6-linux-gnu
x86_64-ol8u6-linux-gnu
i686-ol8u6-linux-gnu
Signed-off-by: Guillermo E. Martinez <guillermo.e.martinez@oracle.com>
glibc-2.23 fails to build for mips with
nptl/libpthread.so:(*IND*+0x0): multiple definition of `vfork@GLIBC_2.0';
This was fixed in glibc-2.24. Backport the fix for glibc-2.23.
Fixes#1744
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>
Commit 6d5227b6 ("Remove obsolete glibc 2.12.1") removed supports for
the separate glibc-ports but also removed GLIBC_USE_PORTS_ADDON. Glibc
versions up to 2.20 bundled support from some architectures in the ports
directory so GLIBC_USE_PORTS_ADDON is required to support these older
glibc versions.
Fixes#1736
Signed-off-by: Chris Packham <judge.packham@gmail.com>
Add 5.17.5
Bump 5.16.9 -> 5.16.20
Bump 5.15.23 -> 5.15.37
Bump 5.10.100 -> 5.10.113
Bump 4.19.229 -> 4.19.241
Bump 4.14.266 -> 4.14.277
Bump 4.9.301 -> 4.9.312
Linux 5.5 made `make headers_check` a no-op and as of 5.17 it has been
removed so add a milestone and use it as a dependency for
KERNEL_LINUX_INSTALL_CHECK.
Signed-off-by: Chris Packham <judge.packham@gmail.com>
These were unintentionally omitted when the new version was added.
Fixes: 2804d686 ("duma: Add version 2.5.21")
Signed-off-by: Chris Packham <judge.packham@gmail.com>
Add duma 2.5.21 and mark 2.5.15 as obsolete. While we're at it use the
versions hosted on github which requres new checksums for the 2.5.15
version because the generated tarballs are different.
It appears we don't need any of the patches we've been carrying for the
older version but we do need to pass CC_FOR_BUILD in addition to HOSTCC.
When 2.5.15 is removed we can drop HOSTCC (and DUMA_CPP, DUMA_SO).
Signed-off-by: Chris Packham <judge.packham@gmail.com>
Some useful suggestions were made in commit 5411e69b ("Update the docker
containers"). This captures them in a more visible place.
Signed-off-by: Chris Packham <judge.packham@gmail.com>
The unified diff patch format will contain slightly more information,
which is helpful when rebasing patches to new releases.
Signed-off-by: Hans-Christian Noren Egtvedt <hegtvedt@cisco.com>
When `CT_NEWLIB_NANO_INSTALL_IN_TARGET=y`, the `nano.specs` file
emitted by the newlib-nano build script contains an invalid include
path, resulting in the full `newlib.h` being included instead of the
nano `newlib.h` by the application.
`=/include/newlib-nano` is not a valid path (`=` does not mean anything
and that string is taken as an include path as-is) and GCC ignores this
include path, resulting in application including the `newlib.h` from
`include/` which contains the newlib build configurations for the full
newlib.
This commit modifies the newlib-nano build script to emit a proper
newlib-nano include path relative to the `GCC_EXEC_PREFIX`.
Signed-off-by: Stephanos Ioannidis <root@stephanos.io>
Previously, cc/gcc.sh assumed that liblto_plugin would always be
installed with the ".so" file extension. However, this assumption is
incorrect when the host machine is Windows (".dll") or MacOS (".dylib").
This patch corrects this issue by probing the file extension in similar
fashion to the way adjacent code determines the file extension of
executable binaries.
Signed-off-by: Joel Holdsworth <jholdsworth@nvidia.com>
The "ext" variable is set with the file extension of executable binaries
for a given platform. To improve tidiness, this patch ensures the
variable is always set even when there is no file path.
Signed-off-by: Joel Holdsworth <jholdsworth@nvidia.com>
In do_gcc_core_backend and do_gcc_backend, variables "file" and "ext"
are used to store intermediate values. Previously, these were not
declared local. This patch corrects this issue.
Signed-off-by: Joel Holdsworth <jholdsworth@nvidia.com>
In Bryan Hundven's patch 1ad439907 from 2010, the author added -lstdc++
and -lm to the host gcc build's LDFLAGS, because at the time the linker
did not correctly include these libraries causing the build to fail.
In modern builds, this causes a problem for canadian gcc builds where
the host machine is mingw32-w64 Windows.
Within the gcc build there is the liblto_plugin module. On Windows this
must be built as the "liblto_plugin.dll" dynamic library. However,
libtool cannot produce a dynamic library unless every library dependency
is also a dynamic library, and falls back to producing a libstdc++.a
static library. liblto_plugin does not require libstdc++ - it
does not contain any C++ code, and the dependency would usually be
elided by the linker.
Unfortunately, in this case, crosstool-ng will never build a
libstdc++.dll dynamic library - only a libstdc++.a static library.
Therefore, there will never be a dynamic library version of stdc++ for
libtool to load and then discard.
This patch corrects the issue by removing "-lstdc++" from LDFLAGS,
because modern versions of gcc are able to correctly include libstdc++
where necessary. It also remove "-lm" for similar reasons.
Signed-off-by: Joel Holdsworth <jholdsworth@nvidia.com>
Drop gdb 7.11.1, 7.12.1, 8.0.1, 8.1.1 and 8.2.1. Cleanup milestones
related to these older versions.
Signed-off-by: Chris Packham <judge.packham@gmail.com>
strace aims to be backwards compatible with older kernels so we don't
actually need to have every strace version. The 4.15-4.26 versions were
technically in a ct-ng release so they were obsoleted. Now that the
1.25.0 release is out we can remove these versions.
Going forward we will obsolete the version that is in the latest ct-ng
release and simply remove intervening strace versions as they are
released.
Signed-off-by: Chris Packham <judge.packham@gmail.com>
glibc 2.12.1 was marked as obsolete. Now that the 1.25.0 release is out
this version can be removed completely. As glibc 2.12.1 was the last
remaining version supported by glibc-ports support for glibc-ports is
also removed.
Signed-off-by: Chris Packham <judge.packham@gmail.com>
The bionic libc support was out of date and relied on downloading
binaries from the internet. It was already marked as obsolete. Now that
the 1.25.0 release is out it can be completely removed.
Signed-off-by: Chris Packham <judge.packham@gmail.com>
The avr-libc project has moved to github and is now using git. Update
the repository field accordingly.
Signed-off-by: Chris Packham <judge.packham@gmail.com>
Modern versions of the 'file' utility give different output for position
dependent and position independent executables. The populate tool should
consider both types.
Signed-off-by: Johan Levin <johan13@gmail.com>
