Rather important option for arm cortex toolchains supporting c++,
avoids pulling in all printf/iostream code by default.
Signed-off-by: Norbert Lange <nolange79@gmail.com>
With libc_headers step before pass-1, there is no need to distinguish
pass-1 and pass-2; they are configured identically (note that with the
current configuration, core pass-2 is only used for win32 - hence, uses
build_libgcc=yes and mode=static).
Signed-off-by: Alexey Neyman <stilor@att.net>
Per https://github.com/crosstool-ng/crosstool-ng/issues/808 build static
libgcc in the first pass which lets us skip the second one. Building
mingw-w64 requires header files in order to build C++ support so mingw
builds core pass 2. This could probably be cleaned up by splitting
libc_start_files into a separate libc_header step. But for now having
core 2 for mingw-w64 and core 1 for the other libcs will have to do.
Anything that previously selected CC_CORE_PASSES_NEEDED now selects
CC_CORE_PASS_1_NEEDED. The same goes for CC_CORE_PASS_2_NEEDED with the
exception of mingw-w64.
Fixes#808Fixes#217
Signed-off-by: Chris Packham <judge.packham@gmail.com>
"--with-host-libstdcxx" option was removed in GCC 6.x, see [1] because of [2].
So it makes no sense to use it with later GCC versions.
Frankly I don't like that implementation with yet another set of "if XXX",
but since we still support GCC down to 4.8.5 what else we may do?
Well, technically we may keep using things as they are now,
because surprisingly GCC's configure script doesn't mind accepting
meaningless options, but as a person who's looking at differences between
various builds and drill-down to peculiarities of various config
options, I'd prefer to not pollute configure with garbage.
But for all the rest... well, it works now and maybe nodody else cares.
[1] https://gcc.gnu.org/git/?p=gcc.git&a=commit;h=5dc85f7ec719a79ecfbcdd8563b07e5f0f365e65
[2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67092
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
GCC 11+ requires compiler being used to support C++11 standard [1].
And while GCC starting from 6.x has C++11 support enabled by default [2],
older versions need to be forced to implement it with "-std=gnu++11" and luckily
GCC's build-system takes care of that:
1. For ${host} compiler - [1]
2. For ${build} compiler - [3, 4]
In a nutshell the configure script tries a couple of options and the one which
helps to build a test source gets appended to CXX (not CXXFLAGS!),
so on say CentOS 7.x with GCC 4.8.5 during cross-compilation of GCC
CXX="x86_64-build_pc-linux-gnu-g++ -std=gnu++11". And all is good.
But in case of canadian cross due to [5] we for some reason* force set
CXX_FOR_BUILD with just a compiler name, effectively overriding all the
magic done by GCC's internals described above.
This leads to a compilation failures like that:
------------------------------------->8----------------------------------
[ALL ] In file included from /usr/include/c++/4.8.2/type_traits:35:0,
[ALL ] from .../HOST-x86_64-apple-darwin14/arc-gcc11-elf/src/gcc/gcc/system.h:244,
[ALL ] from .../HOST-x86_64-apple-darwin14/arc-gcc11-elf/src/gcc/gcc/gengtype.c:26:
[ERROR] /usr/include/c++/4.8.2/bits/c++0x_warning.h:32:2: error: #error This file requires compiler and library support for the ISO C++ 2011 standard. This support is currently experimental, and must be enabled with the -std=c++11 or -std=gnu++11 compiler options.
[ALL ] #error This file requires compiler and library support for the ^
------------------------------------->8----------------------------------
* my guess that [5] was done because back in the day indeed we used to have
"--build=${CT_BUILD} --host=${CT_HOST}" in do_cc_core(). But now after [6]
this is no longer necessary as we use "--build=${CT_BUILD} --host=${CT_BUILD}"
and all is safe and clean. So yet another old quirk goes away - hooray!
[1] https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=5329b59a2e13dabbe2038af0fe2e3cf5fc7f98ed
[2] https://gcc.gnu.org/gcc-6/changes.html
[3] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96612
[4] https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=7ffcf5d61174dda1f39a623e15f7e5d6b98bbafc
[5] 9c6c090d7b
[6] 08161250ed
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
GCC can support using zstd compression for LTO object files. By default
GCC's configure will enable this if libzstd is installed on the machine
building the toolchain. This may be undesirable if the toolchain is to
be used on a different machine. Add an option to control zstd usage and
set the default to the same as the current behaviour (i.e. auto).
Fixes#1579
Signed-off-by: Chris Packham <judge.packham@gmail.com>
Explicitly passing --disable-tm-clone-registry causes gcc to create a
crtbegin.o with a zero-sized .init_array/.fini_array. This in turn
causes ld to complain.
Make CC_GCC_TM_CLONE_REGISTRY a tristate so if it's not explicitly
enabled we can let ./configure decide.
Fixes#1531
Fixes: 1e21a302 ("gcc: Add CT_CC_GCC_TM_CLONE_REGISTRY config")
Signed-off-by: Chris Packham <judge.packham@gmail.com>
This commit adds a new gcc config `CT_CC_GCC_TM_CLONE_REGISTRY` that
enables the GCC transactional memory clone registry feature for libgcc.
Note that the gcc option to control this feature is only available in
gcc 10 and above.
(see gcc commit 5a4602805eb3ebddbc935b102481e63bffc7c5e6)
Signed-off-by: Stephanos Ioannidis <root@stephanos.io>
This commit adds two additional arguments (`cxxflags_for_target` and
`extra_cxxflags_for_target`) for the gcc backend build function that
can be used to specify custom target CXXFLAGS.
By default, the target CXXFLAGS is set to the target CFLAGS. When
`cxxflags_for_target` is specified however, it overrides that behaviour
and allows setting different target CXXFLAGS from the target CFLAGS.
The `extra_cxxflags_for_target` argument can be used to specify the
extra target CXXFLAGS to be appended to the target CXXFLAGS. This is
useful when it is necessary to append CXX-specific flags to the
existing CFLAGS to be used as the target CXXFLAGS.
A useful application of this is building full and nano versions of
libstdc++ with different target CXXFLAGS as necessitated by
`nano.specs`.
Signed-off-by: Stephanos Ioannidis <root@stephanos.io>
The gcc target libraries (e.g. libstdc++) are currently built without
any optimisation flag when `CT_CC_GCC_ENABLE_TARGET_OPTSPACE` is not
enabled and default to `-O0` unless user explicitly specifies an
optimisation flag.
This commit updates the gcc build script to assume `-O2` for building
target libraries unless user provides a different optimisation flag.
Note also that this is the default behaviour for gcc when
C[XX]FLAGS_FOR_TARGET is not overridden.
Signed-off-by: Stephanos Ioannidis <root@stephanos.io>
This adds another mode to do_gcc_core_backend that builds libstdc++
against an alternate libc implementation.
Signed-off-by: Keith Packard <keithp@keithp.com>
Even though GCC as a compiler has nothing to do with a C library
being used it still makes sense to know about Newlib's compact
implementation of IO functions:
* For targets like MSP430 which require to have such a tuned
Newlib if "-mtiny-printf" is passed to the GCC's command-line [1]
* For correct compilation of the following GCC's own DejaGnu tests [2]:
- gcc/testsuite/gcc.c-torture/execute/920501-8.c
- gcc/testsuite/gcc.c-torture/execute/930513-1.c
- gcc/testsuite/gcc.dg/torture/builtin-sprintf.c
- gcc/testsuite/gcc.c-torture/execute/ieee/920810-1.x
[1] https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=02afb6a9321fbfb435452636cedc2cd43f0c4fd2
[2] https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=571bbd0d48d5872eacbd0b681fce6e1ae754520b
So we add that missing cross-dependency now.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
GLIBC 2.31 needs --with-cpu=ultrasparc for both 32/64-bits now, and
--with-cpu only sets the CPU model for the "primary" bitness.
Signed-off-by: Alexey Neyman <stilor@att.net>
... in the backend function with ${CFLAGS_FOR_HOST}. The caller either
supplies them already, or (in case of pass-1/2 of the canadian cross)
passes ${CFLAGS_FOR_BUILD} there.
Signed-off-by: Alexey Neyman <stilor@att.net>
This fixes gccs LIMITS_H_TEST detection for baremetal targets
so limits.h will be installed correctly.
Signed-off-by: Michael Zimmermann <sigmaepsilon92@gmail.com>
1. On SuperH, configuring GCC with explicit variant of the CPU
(like "sh4") limits the default set of multilibs to just that CPU
and requires --with-multilib-list to change. Allow for "unspecified"
variant, so that we can defer to GCC to determine the list.
2. Support toolchains with both endiannesses at the same time.
3. Add a SuperH/newlib sample
4. Add more flags processing for uClibc
Signed-off-by: Alexey Neyman <stilor@att.net>
Some users (like myself) may want to omit the crosstool-NG version
from the binaries' versioning output, as it can be incredibly long
and not too helpful. Add a config option to disable it. The possible
combinations are as follows:
- crosstool-NG version (default)
- crosstool-NG version - custom toolchain ID
- Custom toolchain ID
- No crosstool-NG version OR custom toolchain ID
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
While here, also consider patched by anything other than "bundled patches"
as per-target sources. Add scary warnings in case of a failure.
Signed-off-by: Alexey Neyman <stilor@att.net>
... because there the symbols were constructer part by part.
Also, remove cc.sh and source $(CT_CC).sh directly - we only build
a single compiler at a time.
Signed-off-by: Alexey Neyman <stilor@att.net>
Make this behavior default in case the core gcc backend is used
for final compiler (i.e., for baremetal configurations). Not
setting this option breaks canadian baremetal configurations,
and not setting it makes little sense at all in any baremetal
configuration (since in baremetal we don't have any libc to begin
with).
Signed-off-by: Alexey Neyman <stilor@att.net>
(see the comments in the code for details on the issue)
Old workaround in 100-gcc.sh stopped working (probably, due to one
of GCC version upgrades), so switch to the other approach originally
described there: adjust the list of multilibs to not include the
default target explicitly.
Signed-off-by: Alexey Neyman <stilor@att.net>
It turns out buildroot does not currently accept a toolchain where a dynamic
linker does not reside in the multi-os-directory. Unfortunately this is
how glibc installs itself on AArch64 without any extra tricks.
So, provide an option to force everything into /lib or /usr/lib; patch to
buildroot will be worked on separately.
Signed-off-by: Alexey Neyman <stilor@att.net>
Also a fix for CT_IterateMultilibs: it didn't pass multi_os_dir_gcc, so
it only worked if the caller did *not* declare it as a local variable.
Signed-off-by: Alexey Neyman <stilor@att.net>
