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>
We use the information from various configure time checks to populate
paths.sh. The paths used are all absolute except for the python binary.
In the switch to a more comprehensive check for python by commit
fa05153e ("Make checking for python more predictable.") we ended up
using AC_CHECK_PROGS which checks for the program on the path and sets
the variable to the name of the program. This makes python inconsistent
with the other programs and seems to cause problems for MSYS2. Use
AC_PATH_PROGS instead which does the same check but sets the variable to
the absolute name of the program
Fixes#2047
Signed-off-by: Chris Packham <judge.packham@gmail.com>
add gnatls and gnatlink to list of tools since it is needed to support Ada just like gnatmake and gnatbind
Update crosstool-NG.sh & TODO
Signed-off-by: c-grant <60671494+c-grant@users.noreply.github.com>
more specificaly to the tarballs download. The function CT_Fetch now
touches the already existing files to be comparable to the not used ones
that can araise when a package is updated.
This comparsion is needed because if it would not exist the tarball
would grow in size due to not used but still cached packages.
This would take time but is definitly something to worry about.
Signed-off-by: Quentin Boswank <qubos@outlook.de>
https://www.multiprecision.org/
Add 1.3.1. Mark 1.2.1 as obsolete. Remove 1.0.3 and 1.1.0.
Fixes#2030
Signed-off-by: Chris Packham <judge.packham@gmail.com>
Some m68k variants do have a MMU so the architecture can set
ARCH_USE_MMU. That means we can have a m68k-unknown-linux-gnu
configuration and that m68k-unknown-uclinux-uclibc needs to select
LIBC_UCLIBC_NG since it's no longer the default.
Fixes#2040
Signed-off-by: Chris Packham <judge.packham@gmail.com>
gdb is linked with libtool, which has a different meaning
for -static, and -all-static must be used to get a static executable.
The binutils build script already uses this option for static builds.
Also remove unnecessary -static from cflags for the gdb build.
Signed-off-by: Chris Copeland <chris@chrisnc.net>
This reverts commit 0841e2f820 from 2011,
which disabled plugin support in binutils for static toolchains, citing
build system problems. This problem seems to be resolved.
This also reverts part of 45512b003d from
2017, which disabled LTO in gcc for static toolchains, citing problems
on Arch Linux with loading the LTO plugin from a static binary.
Signed-off-by: Chris Copeland <chris@chrisnc.net>
older binutils dont automatically pick up plugins,
but need to manually use wrappers like gcc-ar.
This fix allows to compile the host toolchain with -ftlo
on debian stretch.
Signed-off-by: Norbert Lange <nolange79@gmail.com>
moxie-unknown-moxiebox has problems building with newlib 4.3
ld: /lib/libc.a(libc_a-closer.o): in function `_close_r':
newlib/libc/reent/closer.c:47: undefined reference to `_close'
There are some Makefile changes in newlib 4.3 and it's likely previously
this config was picking up `_close` from libsim.a. For now just pin the
newlib version back to 4.2 in the moxie-unknown-moxiebox config.
Resolves#2036
Signed-off-by: Chris Packham <judge.packham@gmail.com>
https://www.mpfr.org/mpfr-4.2.1/
This fixes compatibility issues with hosts using newer glibc (>=2.37).
Fixes#2017, #2029
Signed-off-by: Chris Packham <judge.packham@gmail.com>
