| Age | Commit message (Collapse) | Author |
|---|
|
|
|
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
|
|
|
|
|
|
Unfortunately, this does not entirely removes the requirement of
a /bin/sh being present, as awk(1) is invoked during the build to
use popen(3) in one place, a libc function that has a hard-coded
reference to /bin/sh. Nevertheless, using our interpreter wherever
possible greatly reduces the dependency on the host system.
|
|
... in a way that is supported by configure scripts without
any guessing.
|
|
... instead of relying on hard-coded /bin/sh in the #!-line.
Also add our interpreter in scripts that are called directly
during the build.
|
|
... instead of relying on the #!-line that hard-codes /bin/sh.
|
|
... to a version supporting shell toolchains.
|
|
... thus having less requirements on our bootstrapped shell tool chain.
|
|
|
|
In stage 0, bootstrap a pretty complete tool collection, so that
we can bring ourselves the tools needed by the configure scripts
of the early stages.
|
|
|
|
|
|
|
