add --disable-werror to binutils pass1

That does seem like a smart thing to do for robustness since we can't control the host compiler.

Add --disable-werror to binutils-pass1

Added a patch.

While we're on the DIY robustness kick, we might want to also consider using '--disable-shared' to gcc Pass 1, with an appropriate libgcc_eh symlink. See these threads for some reference:

http://www.diy-linux.org/pipermail/diy-linux-dev/2007-August/001068.html http://linuxfromscratch.org/pipermail/lfs-dev/2006-January/055262.html

And his rationale for its effect on temporary Glibc: http://www.diy-linux.org/pipermail/diy-linux-dev/2005-June/000556.html

There's also several switches he passes to minimize what internal libraries gcc builds and to speed up the bootstrap process. Those could be considered as well.

I'm fine with adding pretty much anything in DIY since Greg follows the toolchain really closely for native builds (it's basically "upstream" for me). However, it's a bit late in the game to be performing a big switch of removing libgcc_s for gcc-pass1. I feel confident it would work, but very few people here have done any testing on a bootstrap like that. I would feel pretty bad to introduce a regression on a last minute change. IMO, of course. (To be fair, I've been using --disable-shared in my personal builds for a long time.)

The tweaks are also very nice, but I think they're best left in DIY. It provides a nice separation between the two projects that the one of the primary goals of LFS is to help people learn how to do this. It's one thing to add extra (potentially confusing) commands here because the build becomes more robust, but it's another if it's just to shave a couple minutes off the build. We have to consider the audience here.

I agree with Dan. I don't see the advantage to adding several switches and symbolic links. The purpose of building gcc-pass1 is to use "our" gcc and not the hosts. What we have now works, even if it is a bit of overkill. The costs are a little time and disk space and the disk space can be released for the final build anyway.

The issue in earlier messages about building with RH7 is a non-starter anyway because we need a 2.6 kernel for the host and RH7 was 2.4 based.

The advantage to the current method is simplicity. To me the added complexity cost is not worth the minor gains achieved.

My apologies for adding the suggestion to this ticket. I failed to notice that it was slated for 6.3. My suggestions were meant for 7.0 at least.

Bruce, no offense, but I think your comment about using our gcc and not the hosts shows you misunderstand the purpose of the switches. Of course we want to use our gcc. That is, inded, the point.

The proposed switch of --disable-shared for gcc actually makes less use of the host libraries, as GCC's internal libraries are statically linked. '--disable-shared' is for robustness, as it removes some measure of dependency on the host and is therefore less likely to go wrong.

The other switches are less important. Those 'tweaks' are just disabling other internal libraries that GCC *could* make use of, but doesn't need to for a temporary toolchain, such as libmudflap.

Also, according to the DIY build, the prereqs for a 2.6 kernel seem to be no longer valid.

Anyone else want to comment on --disable-werror? This is the last ticket milestoned to 6.3.

I think it makes sense - it'll save having to add an errata for 6.3 when some host appears with a version of GCC that doesn't compile binutils because of a change in the warnings it outputs.

+1

Great. I have something ready.

Fixed in r8278 and r8280.

Milestone 6.3 deleted