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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
Due to the small flash space on AVR devices the library containing the
standard types in C++ (ˋlibstdc++ˋ) does not get built normally when
enabling the C++ language support.
This option is an easy way to go back to the PC-way where ˋlibstdc++ˋ is
built.
Signed-off-by: Quentin Boswank <qubos@outlook.de>
To build multilib RISC-V toolchain one should use --with-multilib-generator
option instead of --with-multilib-list.
Add corresponding example configuration file.
Signed-off-by: Kirill K. Smirnov <kirill.k.smirnov@gmail.com>
If static cross GDB configuration is selected, cross GDB will be linked
statically with std c++ library, because there is no separate option for
static std c++ library for cross GDB.
The use of not existing variable CT_GDB_NATIVE_STATIC_LIBSTDC has been
replaced with CT_GDB_NATIVE_STATIC_LIBSTDCXX.
Signed-off-by: Maksim Morozov <maxim.morozov.a@gmail.com>
Use a relative path for include directory if gdb or gdbserver
is being built and installed for a target. Otherwise headers
are installed in ${destdir}${CT_HEADERS_DIR} - a concatenation
of ${destdir} and an absolute path to sysroot's include directory.
As a result debug-root may contain wrong paths for includes.
Signed-off-by: Yuriy Kolerov <ykolerov@synopsys.com>
It's necessary for building native GDB 13+. It depends
on MPFR but it hasn't presented in scripts yet for building
for target.
Signed-off-by: Yuriy Kolerov <ykolerov@synopsys.com>
Variable native_extra_config must be used for configuration
options instead for extra_config for native GDB.
Signed-off-by: Yuriy Kolerov <ykolerov@synopsys.com>
Old options %(newlib_nano_link) for the linker must be passed
otherwise linking may fail. E.g., in case of multilib
configurations a correct emulation mode may be not passed.
Signed-off-by: Yuriy Kolerov <ykolerov@synopsys.com>
These values are used when constructing the default linker scripts
used with picolibc. Setting reasonable defaults allows simple test
applications to be compiled without additional configuration.
Signed-off-by: Keith Packard <keithp@keithp.com>
This adds 3 new options to patch order:
* bundled + bundled_exp
* bundled + bundled_exp + local
* local + bundled + bundled_exp
The path for bundled experimental patches is: ${CT_LIB_DIR}/packages/${pkg_dir}/experimental
and patches that are still being reviewed, but not yet applied upstream
may be toggled with ENABLE_EXPERIMENTAL_BUNDLED_PATCHES.
Also fix modelines for editors on bootstrap and scripts/functions, and
fix mix whitespace in scripts/functions.
Closes: #1916
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
This moves the picolibc configuration values under C-library -> picolibc
so that they will be more easily discovered.
Signed-off-by: Joakim Nohlgård <joakim@nohlgard.se>
Picolibc needs two additional gcc build options so that libstdc++
works correctly. When building picolibc as a companion library, those
are added in do_cc_libstdcxx_picolibc, but when built with picolibc as
the main C libary, those need to be added in the main GCC build.
Signed-off-by: Keith Packard <keithp@keithp.com>
Add zstd to the companion libs witch allows to use lto zstd compression
in a canadian or cross-native enviroment
Signed-off-by: QBos07 <62326551+QBos07@users.noreply.github.com>
Signed-off-by: Quentin Boswank <62326551+QBos07@users.noreply.github.com>
libgccjit is still under development and, despite its name, may also be used for
ahead-of-time compilation.
Documentation can be found on the gcc website:
https://gcc.gnu.org/onlinedocs/jit/internals/index.htmlhttps://gcc.gnu.org/wiki/JIT
With this change it's possible to enable the building of the libgccjit. It's
enabled as a language (with --enable-languages=jit) even if not a language
frontend at all.
The main changes are related to the requirement of having everything host side
built as Position Independent Code (PIC) with --enable-host-shared. GCC has the
needed logic for building its dependencies (mpc, gmp, mpfr, ...) correctly when
built "in-tree", which is not the case with crosstool-ng (see
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=05048fc29f0)
Signed-off-by: Marc Poulhiès <dkm@kataplop.net>
BPF is a virtual machine and associated ISA that resides in the Linux
kernel. Initially intended for user-level packet capture and filtering,
BPF is nowadays generalized to serve as a general-purpose infrastructure
also for non-networking purposes.
Signed-off-by: Cupertino Miranda <cupertino.miranda@oracle.com>
Fixes Canadian cross builds failing with missing include file 'stdio.h'
when building libstdc++ for a companion libc with system libc set to
LIBC_NONE.
Signed-off-by: Joakim Nohlgård <joakim@nohlgard.se>
Most scripts in crosstool-ng use [ -z "${string}" ] to check for empty
variables.
Deleted one duplicate declaration of the local exec_prefix
Signed-off-by: Joakim Nohlgård <joakim@nohlgard.se>
If a user deletes the package directory under .build/src/ but fails to
remove the hidden stamp files the CT_DoExtractPatch function will detect
this, delete the stamps and perform the full extract-and-patch step.
Signed-off-by: Joakim Nohlgård <joakim@nohlgard.se>
${CT_PREFIX_DIR} may contain relative paths (e.g.
"${CT_TOP_DIR}/../x-tools/${CT_TARGET}"). Code added in commit d83a0036
("Add symlinks from the libraries' original location to the new one.")
didn't cope well with this. As we're already calculating
${cannon_prefix} make use of it when adding the symlinks. This avoids
any issues with ${CT_PREFIX_DIR}.
Fixes#1807
Signed-off-by: Chris Packham <judge.packham@gmail.com>
