ashes cendres at
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 mailing list