cendres at videotron.ca
Sat Jan 3 03:21:07 PST 2004
On January 3, 2004 12:32 am, Archaic wrote:
> On Sat, Jan 03, 2004 at 12:17:27AM -0500, ashes wrote:
> > If you want propolice on glibc, you need propolice in chapter 5.
> Following the logic in pureLFS, if we have just built a full LFS, we
> should be able to start by patching and building gcc, and use that gcc
> to build binutils, then glibc. As your patches stand now, will gcc have
> to be rebuilt again _after_ glibc is rebuilt (like is done in chapter6),
> or are we not patching glibc with propolice anymore. And if we are, will
> the patched glibc build gcc differently considering it has it's own
> propolice patches? Have I confused anyone, yet? ;)
Glibc has to be patched first, followed by gcc, but the first glibc won't be
guarded. From what I understand, the glibc patch will allow -O3 to be used
without loosing propolice symbols, it will reduce the smash symbols from the
binary. There might be another clear advantage I haven't discovered yet.
It's a chicken/egg problem, we need glibc patched with propolice, and gcc
built against the patched glibc, before glibc can be built with propolice.
I'm also worried about gcc pass 2, since it isn't bootstrapped, the installed
copy of gcc pass two won't be guarded, the make check against gcc pass 2
won't be for a guarded gcc. But, since the spec file hasn't been edited
untill after its installed, there's no easy way to bootstrap propolice into
gcc pass 2. So, maybe gcc chapter 6 should be boostrapped, but by this point
its getting a make bootstrap equivilent since its being built for the second
time against a propolice patched glibc. Because of the advancements in gcc
spec file technology, I'm no longer supporting the protector_only patches.
That patch only passes -fstack-protector, while -fstack-protector-all is
ideal, and is now very easy to add to the gcc spec file so it can be turned
on or off transparently without cflags.
More information about the hlfs-dev