Alexander E. Patrakov wrote: > This is from the current development LFS LiveCD, not FC4, but I assume > the problem is the same:
<snip> > ../../binutils-2.15.94.0.2.2/gas/config/tc-i386.h:443: 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 hosts. > 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 future. Regards Greg -- http://www.diy-linux.org/ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
