3 ms·

Well, if Go 1.4 is the last version almost entirely written in C, then for unsupported architectures/platforms, it seems like it would be the easiest to port fi

Well, if Go 1.4 is the last version almost entirely written in C, then for unsupported architectures/platforms, it seems like it would be the easiest to port first before bootstrapping a new version of Go. Is that not the case? I don't feel like I have this backwards at all. I wasn't commenting on it being a hardship to limit the implementation to Go 1.4's feature set.

rsc 12y ago
I don't see much point to doing two ports (of very different versions of the code base) when you can do one port (of the current version, via cross-compilation) and then copy the result over to your target system and use that as the bootstrap base for future ports. For example, Go 1.4 did not support linux/ppc64, but Go 1.5 will. If you want to build Go 1.5 for linux/ppc64 from source, the simplest thing to do is to cross-compile it on a linux/amd64 system, copy the resulting binaries over to your linux/ppc64 system, and use that toolchain as the bootstrap base for any future work. Doing two ports would work, but the first one is basically wasted effort unless you need to survive every other supported Go system disappearing tomorrow.
- binarycrusader 12y ago
  I'm not sure why I was downvoted into oblivion; but that's actually great news. I was under the impression from reading the boostrap document that this meant I would have to port 1.4 and 1.5. I think I completely misunderstood the new ports section as to how it related to the plan overall. If I can get away with only porting a newer version, that's considerably easier. Thanks for assuaging my fears.
  - binarycrusader 12y ago
    For others following along, I would like to point out that my original conclusion was that 1.4 would be required given the explicit statement in the document: To build Go 1.x, for x ≥ 5, it will be necessary to have Go 1.4 installed already, in $GOROOT_BOOTSTRAP. This is subtly different from the statement in the new ports section of the document: For Go 1.x (x ≥ 5), new ports will have to be done by cross-compiling test binaries on a working system, copying the binaries over to the target, and running and debugging them there.

rsc 12y ago

I don't see much point to doing two ports (of very different versions of the code base) when you can do one port (of the current version, via cross-compilation) and then copy the result over to your target system and use that as the bootstrap base for future ports. For example, Go 1.4 did not support linux/ppc64, but Go 1.5 will. If you want to build Go 1.5 for linux/ppc64 from source, the simplest thing to do is to cross-compile it on a linux/amd64 system, copy the resulting binaries over to your linux/ppc64 system, and use that toolchain as the bootstrap base for any future work. Doing two ports would work, but the first one is basically wasted effort unless you need to survive every other supported Go system disappearing tomorrow.

binarycrusader 12y ago
I'm not sure why I was downvoted into oblivion; but that's actually great news. I was under the impression from reading the boostrap document that this meant I would have to port 1.4 and 1.5. I think I completely misunderstood the new ports section as to how it related to the plan overall. If I can get away with only porting a newer version, that's considerably easier. Thanks for assuaging my fears.
- binarycrusader 12y ago
  For others following along, I would like to point out that my original conclusion was that 1.4 would be required given the explicit statement in the document: To build Go 1.x, for x ≥ 5, it will be necessary to have Go 1.4 installed already, in $GOROOT_BOOTSTRAP. This is subtly different from the statement in the new ports section of the document: For Go 1.x (x ≥ 5), new ports will have to be done by cross-compiling test binaries on a working system, copying the binaries over to the target, and running and debugging them there.