... it is possible to just not set it in the configuration, why force
it? It just increases the complexity in Kconfig.
Signed-off-by: Alexey Neyman <stilor@att.net>
... when determining if it can be linked statically, and if Python
scripting should default to y.
Prompted by a failure of i686-w64-mingw32,nios2-spico-elf sample
on a system where configure didn't report static linking support.
Signed-off-by: Alexey Neyman <stilor@att.net>
None of the bare metal C library choices (avr-libc, newlib) support
installing into sysroot. Nor does it make any sense, since sysroot
implies a file system, which in turn implies an OS.
This commit adds support for the avr-libc C library.
According to the project page at http://www.nongnu.org/avr-libc , the
avr-libc package provides a subset of the standard C library for Atmel
AVR 8-bit RISC microcontrollers. In addition, the library provides the
basic startup code needed by most applications.
Support for this library in crosstool-ng is only enabled for the AVR
8-bit target.
The avr-libc manual and most distributions build the AVR 8-bit gcc
toolchain with the "avr" (non-canonical) target.
Some experimentation also led to the conclusion that other (canonical)
targets are not very well supported, so we force the "avr" target for
crosstool-ng as well.
The manual also recommends building avr-libc after the final gcc build.
To accomplish this with crosstool-ng, a new do_libc_post_cc step is
added, in which currently only avr-libc performs its build, and is a
no-op for the other libc options.
Signed-off-by: Erico Nunes <nunes.erico@gmail.com>
As posted on http://www.eglibc.org/
====================
EGLIBC is no longer developed and such goals are now being addressed
directly in GLIBC.
====================
I'm not interested in maintaining build support for unsupported
software.
Older branches of crosstool-ng continue to have eglibc support.
If you find issues with older branches, I'm always open to pull
requests.
Removing eglibc also frees up glibc cleanup and build optimization.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
It's been some time now we've had those features, so unmark them
being experimental.
It does not mean everything is perfect, but may gather some more
testing of those features.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Currently, we rely on an existing external cross-compiler targetting
the target, to build the C library.
This can pause quite a few problems if that compiler is different from
the one we are building, because it could introduce some ABI issues.
This patch removes this dependency, by building the core compilers
as we do for standard cross, and also by building the binutils and
gcc, for running on the build machine.
This means we no longer need to offer the cross-sompiler selection in
the menuconfig.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Currently, we check host feature in ./configure. This works only for
cross toolchains, but not for canadian toolchains. ./configure has
absolutely no way to know what the host for the toolchain will be;
only the build scripts know.
So, move the headers & libraries checks from ./configure to the build
scripts, early enough in the build, but not before we know the host
compiler and other tools.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Static liunking is not supported on Darwin, so hide the corresponding
options when the build machine is Darwin.
Reported-by: Andrea Franceschini <therealmorpheu5@gmail.com>
Reported-by: Bryan Hundven <bryanhundven@gmail.com>
Reported-by: "Titus von Boxberg" <titus@v9g.de>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
"crosstool-NG-${CT_VERSION}" is currently the default for TOOLCHAIN_PKGVERSION,
and this options is passed as is to --with-pkgversion.
This patch prepends "crosstool-NG ${CT_VERSION}" to TOOLCHAIN_PKGVERSION before
passing it to --with-pkgversion.
Signed-off-by: "Benoît THÉBAUDEAU" <benoit.thebaudeau@advansee.com>
Hide the staticaly linked libstdc++ option if the static libstdc++ is not
present, detected at configure time.
Add a blind option that says whether static linking is possible at all.
It defaults to 'y', but depends on the needed CONFIGURE_* options. For
now, it only depends on static libtdc++, but new dependencies can be
easily added.
Hide the global static toolchain option behind this new option.
Original patch by Bryan Hundven <bryanhundven@gmail.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
This patch makes gdb benefit from the TOOLCHAIN_PKGVERSION and
TOOLCHAIN_BUGURL options.
Signed-off-by: "Benoît THÉBAUDEAU" <benoit.thebaudeau@advansee.com>
This patch makes eglibc benefit from the TOOLCHAIN_PKGVERSION and
TOOLCHAIN_BUGURL options.
Signed-off-by: "Benoît THÉBAUDEAU" <benoit.thebaudeau@advansee.com>
This patch makes binutils benefit from the TOOLCHAIN_PKGVERSION and
TOOLCHAIN_BUGURL options.
Signed-off-by: "Benoît THÉBAUDEAU" <benoit.thebaudeau@advansee.com>
This patch promotes the PKGVERSION and BUGURL options to toolchain level so that
all toolchain components supporting them can benefit from them.
These options are passed to configure through --with-pkgversion and
--with-bugurl.
They are supported by binutils 2.18+, gcc 4.3+, eglibc 2.9+ and gdb 7.0+.
Signed-off-by: "Benoît THÉBAUDEAU" <benoit.thebaudeau@advansee.com>
kconfig bools are disabled by default, so specifying 'default n' is useless and
noisy. This patch removes all occurrences of 'default n'.
Signed-off-by: "Benoît THÉBAUDEAU" <benoit.thebaudeau@advansee.com>
In backend mode, setting the sysroot name is the
responsibility of the upper-layer build system.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Use of the sysroot is highly recommended, and the non-sysroot case is
both obsolete and not widely tested.
Before the non-sysroot case can go away, deprecate it.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Depending on local policies, some users have expressed a need to
have the sysroot be named differently than the hard-coded name.
Add an option for that.
Default to 'sysroot' to match the existing literature.
While at it, replace 'sys-root' with 'sysroot' everywhere we
reference the sysroot.
Reported-by: Alexey Kuznetsov <Alexey.KUZNETSOV@youtransactor.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
If the global static option is set, then build binutils statically.
Signed-off-by: "Bryan Hundven" <bryanhundven@gmail.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
If the global static option is set, then build host binutils statically.
Signed-off-by: "Bryan Hundven" <bryanhundven@gmail.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Add a config option to statically build the host tools.
Impacted tools can use that option to decide wether to build
statically or shared.
For now, no tool uses it, but they'll be added one at a time
in the next commits.
Signed-off-by: "Bryan Hundven" <bryanhundven@gmail.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
When crosstool-NG is used as a backend, it is the responsibility of the
upper-layer build-system to properly set paths, so we just hide the
prompts in this case.
The "Build shared libraries" config option is dependant on the type of
"Target OS".
Moving this options to the "Target OS" sub-menu is also better in the user
perspective: he/she no longer needs to go back and forth to see if he/she
missed any option.
Add the WRAPPER_NEEDED silent config option, that can be selected by
components that require it (companion libs so far).
Rely on this config option when deciding to install the wrapper,
instead of checking GMP/MPFR or PPL/CLoog/MPC.
Add implementation for a candadian build option already
present in crosstool in order to build a cross-compiler
where build != host != target
Signed-off-by: Bart van der Meulen <bartvdrmeulen@gmail.com>
- vendor and alias must not contain spaces
- vendor must not contain dashes '-'
- sed_expr must not generate an alias with a space in it
/trunk/scripts/functions | 17 16 1 0 ++++++++++++++++-
/trunk/config/toolchain.in | 1 1 0 0 +
2 files changed, 17 insertions(+), 1 deletion(-)
- the threading models available are dependent on the C library used
- it is thus easier to first select the C libary, and then the threading model, rather going back to the toolchain menu.
/trunk/config/toolchain.in | 29 0 29 0 -----------------------------
/trunk/config/libc.in | 47 38 9 0 ++++++++++++++++++++++++++++++++++++++---------
2 files changed, 38 insertions(+), 38 deletions(-)
