Code added to deal with --enable-local used the non-existent CT_Error
instead of CT_Abort. Use the correct function so the build aborts with a
useful error message.
Fixes#2141
Signed-off-by: Chris Packham <judge.packham@gmail.com>
* Run `apt-get update` before installing packages, as the local VM may
not have these packages already installed like the github.com runners
do.
* Add bison, flex, and texinfo, as they may not already be on the local
VM as they may be on the github.com runners.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
The native gdb needs the version of libexpat built for the target. On
some systems gdb's configure will find the one from the build machine.
Use --with-expat= to point at the correct one for the target.
Fixes: 2092
Signed-off-by: Chris Packham <judge.packham@gmail.com>
Add the new release and rebase the local patches. Add a new patch which
resolves a build issue on macOS.
https://sourceware.org/pipermail/binutils/2024-January/132213.html
Signed-off-by: Chris Packham <judge.packham@gmail.com>
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
In canadian builds, the target toolchain running on the build
machine is not compiling and installing target Newlib. Thus it
cannot by itself link target executables. This results in
errors for gnuprumcu package when its configure script attempts
to test the compiler:
.../ld: cannot find crt0.o: No such file or directory
configure:3738: error: C compiler cannot create executables
Fix by passing the host toolchains's sysroot in target CFLAGS.
While at it, also add a missing passing of target LDFLAGS.
Successfully tested the following canadian builds:
x86_64-unknown-linux-gnu,pru
x86_64-w64-mingw32,pru
arm-unknown-linux-gnueabihf,pru
Signed-off-by: Dimitar Dimitrov <dimitar@dinux.eu>
The canadian cross builds are hitting the disk space limit on the free
tier github runners. For now disable them.
Signed-off-by: Chris Packham <judge.packham@gmail.com>
This patch adds two gcc commits to fix musl libdir path for loongarch64:
* 13c5de14 ("LoongArch: Fix MUSL_DYNAMIC_LINKER")
* a5f1bdfc ("LoongArch: Modify MUSL_DYNAMIC_LINKER.")
* 2f7d4728 ("LoongArch: Use /lib instead of /lib64 as the library search path for MUSL.")
Signed-off-by: WANG Rui <wangrui@loongson.cn>
Homebrew changed it's default install path from `/usr/local` to
`/opt/homebrew` a while back. Hardcoding the path is a bad idea, so
instead use `$(brew --prefix)` to get the prefix of the path for tools.
Also fix some [shellcheck](https://github.com/koalaman/shellcheck) issues.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
Adapted from the aarch64-unknown-linux-gnu sample enabling
CT_EXPERIMENTAL and selecting CT_LIBC_MUSL.
Signed-off-by: Chris Packham <judge.packham@gmail.com>
Changes since v.0.9.0:
* Add I/O header for am62x.
* Fix bit field length in AM572x's SPP register.
* Add linker commands to align sections.
* Do not use BIG_ENDIAN for a struct field name.
* Minor build system cleanups.
Signed-off-by: Dimitar Dimitrov <dimitar@dinux.eu>
Similar to commit 65e5960a ("gdb: Fix extra config variable name for
native GDB") we need to use cross_extra_config for the options we're
passing to the gdb build when cross compiling.
Fixes: 5463ab4b ("gdb: Add gdb-10.2")
Signed-off-by: Chris Packham <judge.packham@gmail.com>
This reverts commit 57f5909285. This was
originally added so that a toolchain could be built on a newer system but
run on an older one. With the benefit of hindsight that is probably the
wrong approach. The best way of achieving that goal would be to use
docker/podman container to provide an environment that is the same as
the oldest supported system and build inside that. The resulting
toolchain should be compatible with the old system and the new one.
Closes#2094
Signed-off-by: Chris Packham <judge.packham@gmail.com>
This patch removes any dependency to the Oracle UEK Linux sources since
it can be easily replaced by a standard kernel explicitly pointing to
the exact kernel version, as the toolchain building only requires the
kernel headers.
Signed-off-by: Cupertino Miranda <cupertino.miranda@oracle.com>
This patch resolves compilation issues with GCC versions 12 and glibc 2.17.
It corrects the constraints used in the THREAD_SETMEM and
THREAD_SETMEM_NC macros for the movq instruction
in the x86_64 architecture.
Backported from:
b1ec623ed5Closes#1825
Signed-off-by: Artem Panfilov <artem.panfilov@nokia.com>
Starting from GDB 11.x, gmp is needed as a dependency to build full gdb.
And by default build system of native GDB will try to link with libgmp
of the build host. And to make sure that doesn't happen we need to
specify location of the target's sysroot so that library search starts
from there. Which we do in that change.
Fixes [1] & [1].
[1] https://github.com/crosstool-ng/crosstool-ng/issues/2084
[2] https://github.com/crosstool-ng/crosstool-ng/issues/1656
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
We set some variables for linking zlib to '' which we shouldn't do. Let
the Makefile sort these things out.
Signed-off-by: Quentin Boswank <qubos@outlook.de>
Linux kernel versions newer than 5.3 require rsync in order to export
the UAPI headers. Commit f441a6bf ("linux: Add dependency on rsync for
Linux >= 5.3") attempted to address this with a check that runs when
crosstool-ng is built. That had the downside that if crosstool-ng was
built and packaged on a machine that had rsync then run on a machine
that didn't then the build would fail due to the missing rsync.
Conversely if the first machine didn't have rsync installed when
crosstool-ng was built then we would not offer newer kernel versions.
We can address this by checking for rsync when the toolchain
configuration is updated using some functionality in the newer Kconfig
that we've updated to previously.
Fixes#1940
Signed-off-by: Chris Packham <judge.packham@gmail.com>
https://sourceware.org/pipermail/binutils/2023-July/128719.html
Forward ported all patches from binutils 2.40, with only minor
adjustment to match new upstream code in patch
0007-poison-system-directories.patch.
Signed-off-by: Hans-Christian Noren Egtvedt <hegtvedt@cisco.com>
As of binutils 2.41 libbfd.a is not placed directly in the output
directory. Fortunately the libtool .libs location seems to have been
in place for some time so we can update the path without worrying about
backwards compatibility.
Signed-off-by: Chris Packham <judge.packham@gmail.com>
There are a number of things that don't currently work notably uClibc,
C++ and GDB. Mark this architecture as experimental.
Signed-off-by: Chris Packham <judge.packham@gmail.com>
64-bit kernels can support running both 32 and 64-bit user code. Select
hppa-unknown-linux-$LIBC or hppa64-unknown-linux-$LIBC depending on
whether compiler defines LP64 or not.
Always select hppa-unknown-linux-$LIBC with 32-bit kernel. This will
generate 32-bit PA 1.1 code. If PA 2.0 code is desired, user can use a
compiler option to select it.
Signed-off-by: John David Anglin <dave.anglin@bell.net>
Debian and Gentoo use hppa/hppa64 for the PA-RISC ports. These are the
proper CPU designations for configuring most packages.
Signed-off-by: John David Anglin <dave.anglin@bell.net>
Note: The 64-bit target lacks a glibc port and doesn't build. Also,
there is no uclibc support.
Signed-off-by: John David Anglin <dave.anglin@bell.net>
As of version 13.x GDB uses libtool for linking instead of g++ these
take different arguments for static linking. Commit 6146b5a6 ("use
-all-static when building a static gdb") attempted to deal with this but
had the effect of causing older GDB versions to fail to build
statically. Add a new internal flag GDB_CC_LD_LIBTOOL and use this to
decide whether to pass `-static` or `-all-static`.
Fixes#2053
Signed-off-by: Chris Packham <judge.packham@gmail.com>
