bander...@mozilla.com wrote:
>> Actually, this would be pretty much what GCC does: it bootstraps
>> itself in three phases, with just one `make` command. And although
>> the scale is much longer, compiling for example GCC-5.3.0 with GCC
>
> This is also what rustc does - it bootstraps off of itself. rustc is
> a self-hosting systems compiler comparable to gcc. Asking rustc to
> bootstrap off of yet another compiler is just kicking the can down
> the road. Eventually Rust wants to be in the same position as gcc,
> where distros have their own binary lineage and are bootstrapping
> their own compiler.
Sure, once you are on similar level of stability to GCC, it is not such
a big problem. Note that GCC 5.3.0 (to my best knowledge) can be
compiled by GCC-3.4 (10 years difference). Once rustc is capable of
being compiled by a one or two years older version of itself, the
problem is pretty much solved. Even 9 months would be mostly fine.
> If we were to put the effort into transpiling to C (or flat out
> writing a rust compiler in C) so that it could be recompiled it would
> just be an intermediate step until distros have their own bootstrap
> working. Bootstrapping off of transpiled C is not much different than
> bootstrapping off a binary blog. The C is not going to be readable.
Ok, if we are talking about output from LLVM backend, than it is exactly
same as using a binary blob (more below). A simple Rust compiler that
would shorten the chain from point zero to today by a half wouldn't
change that much. If it cut things down to say 10 iterations, it would
help. It wouldn't need to be fast or efficient, since it's product would
only be used once.
>> The problem is having to go through some 300 iterations (even if
>> one would probably do that only once on each distribution release).
>> Which as far as I understand - and please do correct me if I'm
>> wrong - would be the case (presumably because rustc's code is
>> progressively using its own new features).
>
> I don't think anybody is expecting this. And in any case it's so
> impracticable that it's impossible. Distros will pick some existing
> binary snapshot to trust and then bootstrap off their own binaries.
I actually tend to think you are wrong on this one.
I personally would go through the 300 iterations (even if just once)
rather than using a random binary blob. Unless it is signed with a
secure key and that person/corporation is going to take (legal)
responsibility for any security problems caused by the blob itself (i.e.
compiling in a back-door).
Now, while it's not up to me to make these decisions, I can assure you
that these matters are not taken lightly for enterprise Linux.
> From my point of view there are two options that would greatly
>> help:
>>
>> 1) a bootstrapping rust compiler written in C that would work in
>> a small number of rounds as has been described above. It could as
>> well be C++, Python, Perl or whatever can be commonly found in
>> distributions - the lower the better to keep the dependency tree
>> smaller.
>
> If this tool existed it would definitely help fill in the gaps. It
> would be a great amount of work to maintain.
If it is too much of a burden, 300 iterations may suddenly seem more
appealing. Once we get to point where 2) below applies it's (almost) a
piece of cake (I actually mentioned that above already).
>> 2) a more stable rustc codebase - stable in the sense that a
>> recompile would only be necessary on the order of magnitude of ESR
>> releases (note: I'm writing this without any knowledge about
>> current rustc compile requirements). This would allow distributions
>> to perform the long iteration chain once and then update rustc only
>> from time to time.
Thanks
Kind regards
Petr
--
Petr Cerny
Mozilla/OpenSSH maintainer for SUSE Linux
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
