Build stage0/lib/libstd.so using the stage0 compiler.

[msullivan]

This essentially starts the bootstrapping one step earlier by building
the stdlib from source using the stage0 compiler and then using that
stdlib to build the stage1 compiler. (Instead of starting by building
the stage1 compiler and then building a stdlib with it).

This means we should now be able to add features to the stdlib and use
them in the compiler without having to do a snapshot. (On the flip
side, this means that we now need to do a snapshot if we want to use a
new language feature in the stdlib, but that doesn't really seem too
burdensome (we already need to snapshot if we want to use a new
language feature in the compiler)).

[espindola]

I like the idea. Not sure about doing part of the work in stage0.mk and part in stageN.mk, but we can fix that afterwards.
LGTM.

[msullivan]

Putting it in stage0.mk doesn't work because the macro you need to invoke hasn't been defined yet. I guess if we included stageN.mk before stage0.mk...

[brson]

I kind of dislike building into stage0, but don't necessarily see a better solution. If we did this we would probably want to snapshot stage3/libstd.so and not stage3/lib/libstd.so, right?

And if we're going down this path, does it also make sense to do the same thing with rustrt? Snapshot the stage3/ version and build the stage0/lib version.

[msullivan]

I think we want to snapshot the stage3/lib/libstd.so version, and not the stage3/libstd.so version. It doesn't matter for stage3, since they should be the same. But if we were taking a stage1 or stage2 snapshot, we definitely want the version built with the stage1 or stage2 compiler, which means the lib version. (Of course, we want it to wind up as stage0/libstd.so and not stage0/lib/libstd.so.)

I think that it probably does not make sense to build a stage0/lib/rustrt. Since calls into the runtime are generally inserted by the compiler and not called directly, the stage1 compiler won't depend on new runtime features since the stage0 compiler won't be generating calls to them anyways. I might be mistaken about how rustrt is used, though, so...

[brson]

Isn't it true that stageN/rustc always dynamically links to stageN/libstd.so? If that's true then no matter which stage you're at, the stageN/ version of std is the one you need to hold on to, I think. Anyway, that doesn't really affect this patch.

[msullivan]

I updated the patch to instantiate the rules from stage0.mk.

[brson]

Integrated.