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 e63c40854c, 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 39487f1ec0 ("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>
https://sourceware.org/pipermail/gdb-announce/2024/000140.html
The release notes state that "Building GDB and GDBserver now requires a
C++17 compiler (for instance, GCC 9 or later)". Looks like we already
satisfy this requirement with GDB_DEP_NO_STD_FUTURE.
gdbserver now has a dependency on iconv.h, for uclibc configurations we
need to make sure this is satisfied.
Signed-off-by: Chris Packham <judge.packham@gmail.com>
Support for Oracle Linux toolchains have some repetition within their
package directories.
This patch improves the status of package directories and patch reusability.
Signed-off-by: Cupertino Miranda <cupertino.miranda@oracle.com>
Add newly released mold version 2.32.0 from upstream
https://github.com/rui314/mold
New features
- mold supports a feature called Identical Code Folding, or ICF. As the
name suggests, ICF finds identical functions and merges them to reduce
the size of an output file. This is especially effective for
template-heavy C++ programs since templates tend to be instantiated to
the same machine code for different types. For example,
std::vector<int> is likely to be instantiated to the same code as
std::vector<unsigned>. We've made an improvement to our ICF algorithm
so that the --icf feature is ~50% faster than the previous version.
(fa8e95a)
- The -z rodynamic option is now supported for compatibility with LLVM
lld. With the option, mold places the .dynamic section into a
read-only segment. (9a233df)
Bug fixes and compatibility improvements
- Previously, mold behaved differently compared to other linkers if both
-z defs and --undefined=ignore-in-object-files were given (#1270).
Now, they override each other so that the mold's behavior is
compatible with others. (8cd85aa)
- Previously, --dependency-file mistakenly recorded response files as
dependencies (#1258). This bug has been fixed. (4281f45)
- There was a bug that mold corrupted debug info section contents when
the --relocatable option was given (#1265). This issue has been fixed.
(08b0a16)
- [PPC64] The R_PPC64_TPREL16_LO_DS relocation type is supported.
(a8cd2e8)
- [ARM64, PPC64, LoongArch] mold 2.31.0 or earlier may have failed with
an assertion failure when creating a large output file (#1224). This
issue has been resolved. (c7c8583)
Signed-off-by: Hans-Christian Noren Egtvedt <egtvedt@samfundet.no>
Allows building the #mold linker, which can then be used in the
cross-toolchain by passing the -fuse-ld=mold to the gcc flags. It is
much faster than ld or gold.
This requires a C++20 compiler and cmake.
Initially implemented by Arnaud, and HC added configure check for cmake.
Outstanding task to validate compiler is C++20 compatible.
Signed-off-by: Arnaud Vrac <avrac@freebox.fr>
Signed-off-by: Hans-Christian Noren Egtvedt <egtvedt@samfundet.no>
Both D and GNAT have their own runtimes (resp. libphotos and libada).
It is still possible to build the compiler proper without any runtime,
and have an external runtime installed later. This is most commonly
found in embedded systems.
An example for D is: https://github.com/KitsunebiGames/tinyd-rt
An example for Ada: https://github.com/Fabien-Chouteau/bare_runtime
Signed-off-by: Marc Poulhiès <dkm@kataplop.net>
Musl was marked experimental in commit 08d91d41 ("musl: config is broken
for !EXPERIMENTAL"). Most of the reasoning for that change no longer
applies and as it's been about 8 years it's time to let musl loose on
the world. Drop the `depends on EXPERIMENTAL` and update the sample
configs for aarch64 and x86_64.
For powerpc64 the ABI needs to be elfv2. Enforce this via the powerpc
config. Add a sample configuration for powerpc-unknown-linux-musl.
Signed-off-by: Chris Packham <judge.packham@gmail.com>
