Age | Commit message (Collapse) | Author |
|
Also add a reliable mirror for ftp.gnu.org which occasionally is overloaded.
|
|
|
|
|
|
Those are a documented entry-point for the bootstrappable toolchain.
As such, they should be export targets, so the bootstrappable toolchain
can be used as an entirely absent repository.
|
|
This is handled similarly to the AR tool, i.e., provided from
binutils.
|
|
As a side-effect, this configuration of binutils also provides the
DWARF packing utility (dwp).
|
|
|
|
|
|
Add new TOOLCHAIN_CONFIG flag that enables the lld project in the
built toolchain.
|
|
|
|
|
|
|
|
|
|
|
|
During the initial bootstrap phase, an old autotools project (gcc
4.7.4) is built and this potentially with a new compiler. For some
of the tests carried out by the autotools, the compiler is used
without the CFLAGS provided. Therefore, offer to wrap the compiler
with the given flags to avoid that the autotools draw incorrect
conclusions if the compile attempt fails for a different reason,
e.g., because implicit declarations are now considered errors by
default by modern C compilers.
|
|
See https://bugs.busybox.net/show_bug.cgi?id=15931 for details of the
fix not yet upstreamed.
|
|
Co-authored-by: Paul Cristian Sarbu <paul.cristian.sarbu@huawei.com>
|
|
|
|
...to avoid potential staging conflicts.
|
|
|
|
|
|
|
|
|
|
|
|
... and drop unneeded duplication as well as wrong expansion
variables in "PATH" fields.
|
|
... instead of hard-coding the name cmake.
|
|
... as that is brought in by the shell toolchain anyway. In that
way, we can also drop setting "PATH" and hence get rid of the
assumption that variable-expansion happens in "PATH" strings.
|
|
The "PATH" field in ["CC", "defaults"] is taken literally (currently
outside the foreign rules, in the future everywhere), so a reference
to the toolchain does not work. However, it is not necessary either,
so simply drop it.
|
|
... instead of relying on cmake to pick it up from path.
|
|
... as, during bootstrap, when searching for a make utility,
the environment variable ${MAKE} is not honored as default
for CMAKE_MAKE_PROGRAM.
|
|
... so that other tools of the CC toolchain that might be called directly are available.
|
|
... as certain configure scripts call the compiler by basename
|
|
|
|
The main use of the bootstrappable toolchain is to just-import-git(1)
it as toolchain to an existing project. However, it is an explicitly
supported use case to build just the toolchain as stand-alone binaries.
Therefore, also for that use case, make sure all repositories are
content fixed, so that the various bootstrap stages are eligible
for caching as export targets.
|
|
|
|
|
|
... and not only the bootstrap one. For tests, it is useful to
have tools like realpath(1) and date(1) that are not needed for
bootstrapping.
|
|
|
|
... and also add the missing bindings for the remaining test rules.
|
|
|
|
... so that we can install-with-deps the wrapper, in case the bootstrap
compiler has dependencies not present on the host machine.
|
|
|
|
|
|
The environment variable PATH is taken literally by the shell, without
any expansion. So, having a string like "$(TOOLCHAIN)/clang/bin"
in PATH does not change anything as we do not have a directory
with that name. Drop it for now. In the future we might add "bin
dirs" to the CC toolchain as well, but as long as our rules do not
support this, drop the wrong entry here.
|
|
|
|
|
|
... instead of generic to support bringing in a toolchain.
|
|
|
|
|
|
... using the full busybox from stage-0
|