| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
This is the new canonical ordering.
|
| | |
|
| | |
|
| |
|
|
| |
Rubber-stamped-by: Richard Maw
|
| |\
| |
| |
| | |
Reviewed-by: Lars Wirzenius
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
| |
The diff is unfortunately useless as the build-essential has lost all
formatting, but apart from the usual changes to use different branches,
two new chunks have been added.
Before stage2-gcc there is now stage2-gcc-fixed-headers, which updates
stage1-gcc's internal headers to use limits from system headers.
This was previously done at the beginning of stage2-gcc, but required
changes to the staging area.
There is now also stage2-reset-specs before stage3, which does a nasty
hack to prevent gcc using the sysroot specs in the chroot.
|
| | |
|
| |\
| |
| |
| |
| |
| | |
'origin/baserock/richardmaw/inspect-zlib'
Reviewed-by: Daniel Silverstone, briefly in person.
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The stage 1 toolchain is built with --disable-shared, which means
it is unable to build shared libraries.
This causes it to include symbols from libgcc in the zlib shared object.
This causes problems in pass 3, since by then we have a toolchain
that is suitable for building shared objects, so it doesn't include
libgcc symbols in zlib.
This causes problems while building gcc, since cc1 is compiled against
the zlib in /tools, but is run with the zlib in /usr, so it fails
to run due to missing symbols, which would otherwise come from
libgcc_s or be copiled in as part of libgcc.a.
stage 2 zlib was originally added to avoid gcc and binutils needing
to use their embedded copy, which would improve compile speed slightly
and the other reasons to prefer shared objects.
However, the bootstrap is fragile enough without it, it may be the case
that gcc and binutils prefer to embed zlib for precisely these reasons.
|
| |
|
|
| |
I'm not sure how these got lost.
|
| |
|
|
|
|
| |
It's never good to have multiple versions of the same library in use
on a system, so we should avoid using the versions of ZLib that are
bundled in the GCC and Binutils releases.
|
| | |
|
| |
|
|
|
|
|
| |
The build-essential branch of gcc is made to build with a
build-essential staging-filler, while the master branch isn't.
Reviewed-by: Lars Wirzenius <lars.wirzenius@codethink.co.uk>
|
| | |
|
| | |
|
| | |
|
|
|
This patch rewrites the Baserock morphologies so that they can be
built using a minimal "build-essential" staging filler, as described
in my previous patch mail.
The Baserock system is split up into three strata:
- build-essential: the minimum set of tools that can rebuild
itself (from tarballs)
- core: the remaining set of components necessary to produce
a Baserock system which can rebuild itself from source
- tools: auxiliary development tools and libraries
The 'build-essential' stratum does not specify any build
dependencies, because it expects to be built with a staging filler
containing itself. In effect, the stratum has a circular dependency
on itself, which we solve by using a staging filler. The 'core'
stratum depends on only on 'build-essential'. This ensures that all
build dependencies between chunks in 'core' are explicit. These
strata can also be built with the staging filler from the water-bomb
release.
The distinction between a base and a devel system is no longer
defined by the 'foundation' and 'devel' strata (in practice these
had various hidden build dependencies between each other). The size
of a base system is larger than before, due to more development tools
being in 'core'.
|
