FC4 host (was Re: [RFC] LFS-6.1.1)

Greg Schafer gschafer at zip.com.au
Mon Oct 10 15:04:50 PDT 2005

Alexander E. Patrakov wrote:

> This is from the current development LFS LiveCD, not FC4, but I assume 
> the problem is the same:


> ../../binutils- error: array type 
> has incomplete element type
> make[3]: *** [app.o] Error 1

Ok, thanks for clarifying.

>> Does passing --disable-werror help?
> No, as there is no -Werror on gcc command line, and compilation passed 
> past many warnings above that error.

Ok. --disable-werror is needed with newer HJL releases for pass1 on some

> In binutils-2.16.1, they moved "struct relax_type" definition from 
> gas/tc.h to gas/as.h. See backport in the attached patch.

Yes. There is also a GCC4 patch for the testsuite but that isn't really
required for bootstrapping binutils-pass1.

> If there are no other problems further in the build, 
> please include the patch into 6.1.1 instead of blacklisting gcc4-based 
> hosts.

Yes. Even including the patch on the errata page would be far better than
telling folks they cannot use FC4 hosts.

> But the problem is in the "stable" LFS.

Yes. This whole problem adds even more weight to the theory that labeling
LFS "releases" with version numbers is not a good idea. Forgetting about
releases altogether would solve a lot of problems. Instead, just run with
a living, breathing, evolving docco. Once the automated "build directly
from the XML source" stuff is stabilized, terms such as "stable" and
"development" start to become less relevant IMHO.

> Probably you are right that such known "host bootstrap" problems should 
> be fixed in stable dot releases. The main problem here is that they pop 
> up only after the release, and there's no way to predict them. Some 
> warning about the possibility of unknown "downgrade" issues of this kind 
> is still appropriate.

I'll suggest it again, Errata.

> Let's see if today's DIY-linux buildability 
> survives after FC5 or FC6 comes out.

That's a ridiculous statement and you know it. Build recipes (LFS, DIY
etc) will always be evolving documents. Expecting today's techniques to
work on tomorrow's software is unrealistic. The trick is to come up with
robust build methodology that stands the best chance of surviving into the


More information about the lfs-dev mailing list