There is subtle difference between our CTNG_PYTHON and the AX_PYTHON on
which it is based. The latter uses AC_CHECK_PROGS() which sets
PYTHON_BIN to the name of the executable. We use AC_PATH_PROGS() which
sets PYTHON_BIN to the full path of the executable.
Because the name of the executable is the same as the library AX_PYTHON
uses this when looking for the library with AC_CHECK_LIB() which magics
itself into a linker flag like `-lpython3.11` but our version ends up
with a nonsensical `-l/usr/bin/python3.11` so the check fails and we
keep iterating repeating the same wrong check for every tested python
version.
We can't just switch to using AC_CHECK_PROGS() because we do want to use
the variable set by AC_PATH_PROGS() to set the full path in paths.sh.
Ultimately we could probably switch to using the upstream AX_PYTHON
macro (https://www.gnu.org/software/autoconf-archive/ax_python.html) and
figure out a better way of getting the full path of the exectuable but
for now add an extra AC_CHECK_PROGS() to set a different variable and
use that for AC_CHECK_LIB().
Signed-off-by: Chris Packham <judge.packham@gmail.com>
Update the ol7u9 configs to use versions of isl and cloog that work with
the version of GCC that oracle uses. Add a note that these configs are
obsolete. They will be dropped after the next release.
Signed-off-by: Chris Packham <judge.packham@gmail.com>
Some obsolete cloog versions were dropped in commit 41d4583a ("cloog:
Remove obsolete versions"). Unfortunately the ol7-u9 configs don't work
with newer versions of cloog. For now reinstate this version, after the
next release we'll drop it again along with the ol7-u9 configs.
Signed-off-by: Chris Packham <judge.packham@gmail.com>
Some obsolete isl versions were removed in commit 04dce680 ("isl: Remove
obsolete versions"). Unfortunately the ol7-u9 configs don't work with
newer versions of isl. For now reinstate this version, after the next
release we'll drop it again along with the ol7-u9 configs.
Signed-off-by: Chris Packham <judge.packham@gmail.com>
When the bpf-unknown-none sample was added the target support was not in
a released version of binutils or gcc. The support has been in a few
versions of each of these for a while now. Update the sample to use
released versions instead of potentially unstable versions from
upstream.
Signed-off-by: Chris Packham <judge.packham@gmail.com>
The custom uclibc has compile errors with GCC 14. Ignoring that even a
bare metal config fails to build (assembler errors in libgcc) with GCC
14. For now pin the sample config to GCC 13 since that seems to work.
Signed-off-by: Chris Packham <judge.packham@gmail.com>
As per https://gcc.gnu.org/gcc-14/changes.html nios2 will be removed in
GCC 15. Even in GCC 14 we need to pass --enable-obsolete to allow this
target. Update our samples accordingly.
Signed-off-by: Chris Packham <judge.packham@gmail.com>
This target is in GCC/binutils/Linux/Glibc/musl for a while.
Baremetal/glibc/musl toolchains are all build tested.
Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
When building picolibc as a companion library the configure step can end
up picking up certain headers from the build system which causes build
failures. Pass an appropriate --with-headers= to the GCC back end when
building picolibc as a companion library so that the correct headers are
detected by ./configure.
Signed-off-by: Chris Packham <judge.packham@gmail.com>
When building for bare metal only do_gcc_core_backend() is used. In
order to support GCC plugins the --enable-plugin needs to be passed to
GCC's configure.
Fixes#2244
Signed-off-by: Chris Packham <judge.packham@gmail.com>
Ltrace requires an OS. Add a depend to prevent ltrace from being
selected when building for bare metal.
Fixes#1555, #2240
Signed-off-by: Chris Packham <judge.packham@gmail.com>
Should not cause major unwanted behavior changes
- C++ is now selected by default in many configs.
Signed-off-by: QBos07 <qubos@outlook.de>
[cp: depend on CC_LANG_CXX instead of select]
Signed-off-by: Chris Packham <judge.packham@gmail.com>
With gdb15.2 gdb uses libtool for linking, but gdbserver is not.
Should not break #2230 or #2053
Signed-off-by: Michał Zagórski <zagura6+github@gmail.com>
Use --with-libexpat-type=static to search for static libexpat in gdb
native. This should fix#2230.
Signed-off-by: Michał Zagórski <zagura6+github@gmail.com>
GitHub has dropped support for macos-12.
https://github.com/actions/runner-images/issues/10721
We had problems with macos-14 when it was first rolled out. Lets give
macos-13 a try. We'll probably have to migrate to macos-14 or macos-15
eventually but hopefully we can leave that until after the ct-ng 1.27.0
release.
Signed-off-by: Chris Packham <judge.packham@gmail.com>
The mold build was using gcc in the PATH, instead of the shiny gcc we
just built (the way the other companion libs/tools do)
Signed-off-by: Mike Lundy <mlundy@splunk.com>
In some distributions (as Fedora), wget2 is used instead of wget. wget2
doesn't support the --passive-ftp option causing every download to fail.
Also, according to wget's NEWS file [0], --passive-ftp is already the
default in wget since 1.10.
Remove the --passive-ftp from wget's default options.
[0] https://gitlab.com/gnuwget/wget/-/blob/master/NEWS#L733
Signed-off-by: Bastien Curutchet <bastien.curutchet@bootlin.com>
GDB_CC_LD_LIBTOOL doesn't exist and so else branch always taken.
We should use CT_GDB_CC_LD_LIBTOOL.
Signed-off-by: demin.han <demin.han@starfivetech.com>
As of GCC14 implicit-int has been upgraded to an error. While this is
generally a good idea it trips up some older code (particularly in
autoconf generated configure scripts). Add -Wno-implicit-int to CFLAGS
for glibc when using an old GLIBC with a new GCC.
Fixes#2208
Signed-off-by: Chris Packham <judge.packham@gmail.com>
The final gcc build process was relying on `CT_CC_SYSROOT_ARG` to
provide the `--with-headers` argument pointing to the libc header
directory.
Since `CT_CC_SYSROOT_ARG` no longer provides `--with-headers`, this adds
one directly to the final gcc build invocation.
Without this, gcc build system will not copy all the required libc
headers into the `sys-include` directory.
Signed-off-by: Stephanos Ioannidis <root@stephanos.io>
When building a non-sysrooted toolchain, `--with-headers` argument is
specified in `CT_CC_SYSROOT_ARG` as a hack, supposedly because "final
gcc will define disable_glibc while building libgcc, and you'll have no
profiling."
This, however, leads to `--with-headers` being specified multiple times
when building libstdc++ for additional libc variants (e.g. newlib-nano
and picolibc) and results in wrong libc headers being used by the
libstdc++ build under certain circumstances -- GCC does not use the last
specified `--with-headers` when building for macOS and Windows hosts.
Since the above hack is intended for glibc only, this commit adds a
check to ensure that `--with-headers` is added to `CT_CC_SYSROOT_ARG`
only when building glibc.
Signed-off-by: Stephanos Ioannidis <root@stephanos.io>
Meson and Ninja are used by picolibc. Explicitly install these tools
which we appear to have been getting by some transitive dependency up to
now.
Signed-off-by: Chris Packham <judge.packham@gmail.com>
- Also adds the avr-libc GitHub repository as a mirror, as newer
versions seem to be released there. Caters for their release tag
formatting.
Signed-off-by: Nick Brassel <nick@tzarc.org>
Versions of GNU make newer than 4.4 trigger a hang in versions of glibc
older than 2.31. In e63c40854c977f488bee159a8f8ebf5fc06c8666, this was
fixed when the host platform provided make >= 4.4. However, if the
host distro provides only an ancient version of make, crosstool-ng would
still build make 4.4 as a comp tool, which would fail to build glibc.
Extend the previous workaround to build make 4.3 when building old
glibc versions which require it.
See also: #1946
Signed-off-by: Charles Baylis <cbaylis@fishzet.co.uk>
We have been building the multi threaded zstd target. This requires that
anything that links with lzstd also links with lpthread. On more recent
systems this is fine because lpthread is part of GNU libc so the
-pthread option is a no-op but on other systems this will cause GCC to
either fail to build or to silently disable zstd compression. By
building the libzstd.a-nomt-release we can be compatible with older GCC
versions and ensure that support for zstd is not silently dropped.
Fixes: #2198
Signed-off-by: Chris Packham <judge.packham@gmail.com>
In commit 39487f1ec0ab ("newlib: Add 4.4.0.20231231") new
version of Newlib was added, now let's add a reference to that
in the "nano" flavor of Newlib.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
It's been a while since RISC-V support was added to CT-NG in 2017.
Since then RISC-V support was integrated in all the key toolchain
components upstream and now are proven to be in a very good state.
Thus it makes no sense to keep this architecture "hidden" in
experimental options, so we promote RISC-V architecture in CT-NG.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Update to the latest version and bring in an upstream patch for
generating portable .specs files.
Fixes: #2171
Signed-off-by: Chris Packham <judge.packham@gmail.com>
Add newly released mold version 2.33.0 from upstream
https://github.com/rui314/mold
New features
- mold gained a new linker flag --separate-debug-file to bundle debug
info sections into a separate file instead of putting them into a main
output file. You can optionally specify a filename in the form of
--separate-debug-file=<filename>. By default, a debug info file is
created in the same directory as the main output file with the .dbg
extension. mold embeds the debug file's filename into the main output
file so that gdb can automatically follow the link to find debug info
when debugging the main output file.
- The main objective of this flag is to speed up the mold linker even
more. By default, mold creates a separate debug file in the background
after creating a main output file, so that you can start running the
executable as soon as possible while mold is still working on linking
its debug info sections. For example, linking clang with debug info
normally takes ~1.70s on a Threadripper 7980X machine, while it takes
only ~0.52s with --separate-debug-info. Shaving off a full second in
quick edit-rebuild-run cycles should improve programmers'
productivity. If you do not want mold to work in the background, pass
the --no-detach option. (596ffa9)
- mold now supports the --no-allow-shlib-undefined flag. If the option
is given, mold checks if all undefined symbols are resolved not only
for input object files but also for shared libraries passed to the
linker. To use the feature, you need to pass all shared libraries,
including transitively dependent ones, to the linker so that the
linker can resolve all symbols that are available at runtime.
(3001f02)
- mold gained the --dynamic-list-data flag for the sake of compatibility
with GNU ld. If the flag is given, all data symbols are exported as
dynamic symbols. (dd8d971)
- [x86-64] -z x86-64-v2, -z x86-64-v3, -z x86-64-v4 flags are supported.
(5606087)
Bug fixes and compatibility improvements
- [x86-64] Recent x86-64 processors support Intel CET to protect control
flow integrity. When the feature is enabled, the instruction that is
executed immediately after an indirect branch must be endbr64 or a CPU
fault will raise. In other words, it restricts the locations where the
control can transfer to with indirect branches. Doing that makes ROP
attacks harder to conduct.
- A problem with that is the compiler needs to conservatively emit an
endbr64 at the beginning of each global function because the compiler
doesn't know whether or not the function's address is taken in other
translation units. As a result, the resulting binary contains more
endbr64s than necessary, weakening the protection.
- mold supports the -z rewrite-endbr option to conduct a whole program
analysis and rewrite endbr64 with nop if a function's address is not
actually taken within the program. Previously, mold didn't take
section symbols into account when conducting the analysis, which
resulted in culling some endbr64s that must not be removed. Now, the
bug has been fixed. We confirmed that mold can build itself with -z
rewrite-endbr, and the resulting mold executable works fine with Intel
CET. (ed7eec5)
- mold now creates a .eh_frame section even if it's empty. (14a4b05)
- [LoongArch] The following relocations are now supported:
R_LARCH_TLS_LE_HI20_R, R_LARCH_TLS_LE_ADD_R, R_LARCH_TLS_LE_LO12_R,
R_LARCH_CALL36, R_LARCH_RELAX (36e5b4b, 98a7cff, 2c6f379)
- [LoongArch] Some relaxations that reduce the section size are now
supported. (74b359f, 121f917)
- [LoongArch] Range extension thunk support has been removed in favor of
R_LARCH_CALL36 relocations. (47c092a)
Signed-off-by: Hans-Christian Noren Egtvedt <egtvedt@samfundet.no>
Since commit 16c6cc99 ("Save the toolchain configuration to its own
file, as an auto-extracting shell script:") we've been saving the
configuration as a self extracting script. This is a little non-obvious
as it looks like it should be a regular file but the bzipped payload
means it can be easily inspected. It may also cause alarm for users who
should rightly be suspicious of unexpected binaries that get shipped
along with packaged toolchains. It also assumes that bzip2 (or at least
bzcat) is available on the machine running the toolchain.
Instead of the self extracting shell script save the config as a regular
compressed file with an obvious file extension.
Signed-off-by: Chris Packham <judge.packham@gmail.com>
gold uses g++ to link which doesn't recognise -all-static. It appears as
if -static should work for both libtool and g++ but for some reason it
doesn't. Remove the restriction that gold can't be included in a static
toolchain. When a static toolchain is requested pass
--with-gold-ldflags=--static to configure. Finally build gold separately
so it does not get the extra_make_flags which may contain -all-static.
Signed-off-by: Chris Packham <judge.packham@gmail.com>
Based on the configure.ac for binutils it appears that arm, loongarch,
mips, powerpc, s390, sparch and x86 are supported. Expand the list of
architectures that gold is allowed to be used on.
Signed-off-by: Chris Packham <judge.packham@gmail.com>
