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>
... while making use of the new tunables.
Also, unmark the moxie-elf as broken: the ld scripts installed by newlib
can be found by the compiler and can link the binaries. Why the default
script is broken is not ct-ng's problem...
Signed-off-by: Alexey Neyman <stilor@att.net>
This required some rework of the libc selection, as moxiebox is a layer on
top of another libc - newlib.
Also, moxiebox'es host VM (`sandbox`) needs a libcrypto on the host. We will
not have it if we're cross-compiling a canadian cross. Fortunately, all moxiebox
needs from libcrypto is SHA256, and it already includes a standalone implementation
of SHA256 in its runtime. Provide a little wrapper that allows moxiebox use
that implementation for the host binary, too.
Also, automate collecting/printing the list of all packages in a given category
(e.g. LIBC or COMP_TOOLS), generate a list of all Kconfig symbols for a given
category.
Signed-off-by: Alexey Neyman <stilor@att.net>
