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>
A toolchain uclibc-ng-1.0.43, binutils-2.40 and gcc-13.2.0 hits the
following error when building:
ld.bfd: isl_test2.o: non-canonical reference to canonical protected function `__pthread_key_create' in x86_64-multilib-linux-uclibc/sysroot/lib64/libc.so.1
ld.bfd: failed to set dynamic section sizes: bad value
The reference comes from libgcc where it is using the
__pthread_key_create() symbol to detect the use of pthreads with GNU
libc. Prevent this on uclibc-ng with an explicit condition.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111322
Signed-off-by: Chris Packham <judge.packham@gmail.com>
NEWLIB_GLOBAL_ATEXIT needs to be set to y for modern newlib versions.
Commit 227d99d7 ("newlib: add 4.3.0.20230120") ensured this was done.
But xtensa-fsf-elf uses a newlib version from before this so it needs to
explicitly opt out.
Signed-off-by: Chris Packham <judge.packham@gmail.com>
glibc-2.28 complains:
configure: error: use a compatible toolchain or configure with --disable-mathvec (this results in incomplete ABI).
Apparently this is a problem in the way GCC passes the -mcpu and -march
values to the assembler. As a workaround have the configure check pass
-mcpu as well to override anything we're passing in the environment.
Patch and explanation taken from the Yocto project with thanks.
Signed-off-by: Chris Packham <judge.packham@gmail.com>
CC_CC_GCC_ENABLE_DEFAULT_PIE=n is invalid Kconfig syntax for an option
that was intentionally disabled the saved config would be
'# CC_CC_GCC_ENABLE_DEFAULT_PIE is not set'
but the DEFAULT_PIE option isn't selectable for RISCV && BARE_METAL so
the correct thing to do is just remove the config.
This also picks up a change regenerating the saved sample due to changes
in the Kconfig ordering.
Fixes#2019
Signed-off-by: Chris Packham <judge.packham@gmail.com>
As of glibc-2.38 libcrypt is not built by default. Add an option to
allow building libcrypt support into glibc.
Signed-off-by: Chris Packham <judge.packham@gmail.com>
The folder 'packages' is processed in bootstrap, so there is no
need to process it again in Makefile.
This fixes a regression introduced in eb62ec3fbe
Signed-off-by: Kirill K. Smirnov <kirill.k.smirnov@gmail.com>
libsanitizer has problems intercepting crypt() and crypt_r() with newer
glibcs. Bring in an upstream patch that drops support for these from
ASAN.
d7bead8336https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111057Fixes#2010
Signed-off-by: Chris Packham <judge.packham@gmail.com>
