On 05/07/2011 7:29 AM, Marijn Haverbeke wrote:
A way to think of it: imagine there was another rust compiler (visual rust),
if you started the bootstrap of our compiler using it (stage0 is visual
rust), stage1 would depend on the runtime libraries of visual rust.
Right, and if visual rust used a different dynamic lib format, you'd
have a problem. Similarly, if we ever want to change our so format in
an incompatible way, it seems we're in for some seriously complicated
snapshotting.
What is the problem with using the stage0 compiler to first compile a
standard lib for stage1, and then a stage1 rustc? Isn't the current
situation, where (if I understand correctly) stage0/lib/libstd.so is
used both by stage0/rustc and stage1/rustc kind of asymmetrical and
weird?
We have done it both ways in the past; there's always an asymmetry of
some sort because there are always 2 libraries involved, host and target.
You have to be more precise with your term "used by". Stage1/rustc
depends on stage0/lib/libstd.so to *run*, but produces binaries that
depend on stage1/lib/libstd.so. So in a way, it uses both.
I talked to Rafael a bit more about this last week and the arrangement
we agreed we should move to (which, incidentally, works on windows as
well, where there's no rpath support) is the following:
stageN/bin/{rustc,libstd.so,glue.o} <-- host binaries
stageN/lib/<arch>/{glue.o,libstd.so} <-- target[1] binaries
That is: stageN/bin contains everything needed-to-run stageN/bin,
whereas stageN/<arch>/lib contains everything
needed-by-programs-produced-by stageN. Then we rpath stageN/bin/rustc to
$ORIGIN on machines that have rpath, and on windows this "just works"
because it searches the exe directory for dlls. Because it's crazy.
Then we copy stageN/<host-arch>/lib/* to stageN+1/bin while building; no
cross-stage dependencies. You can always just tar up a stageN directory
and transport it. Self-contained.
I just haven't got around to implementing it yet. Still fighting the
windows tinderbox.
-Graydon
[1] This design should work for cross and multi-target configs (which I
very much want rustc to support), but it might not work for
canadian-cross configs. Or at least it'll take some thinking. Self
hosting and canadian-cross configs interact somewhat strongly; we would
need to stop after stage1 if we can't run the host binaries! On the
other hand, the mingw-cross config shows one simple approach, which is
to only support canadian-cross configs where we *can* run the host
binaries, just under an emulator or adaptor of some sort (wine, in this
case; qemu-user would work in other cases). Anyway, that's a bit of a
longer-term concern and I'll carry on fiddling with it, shouldn't affect
the stageN / stageN+1 structure.
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
