>> Given the addition of this toolchain, one wonders how far we are from >> being able to port all the P9 compilers to Linux and consequently to >> all Posix platforms. My beef is that I have a wide choice of cross- >> and native toolchains with which to port Plan 9 to a MIPS platform >> (LSB), but I really wish I could settle on something I am much more >> comfortable and familiar with. > > I guess I'm not following your line of thought here.
There are two almost orthogonal issues here: "go" itself and the toolchain that it relies on. Whereas I do care about "go" and would dearly like to assimilate it into my toolkit, my more immediate interest lies with porting native Plan 9 "C" facilities beyond the Plan 9 boundaries, specifically into the various environments served by the "ELF" object format. Worse, my wish is for the Plan 9 kernel to be able to cope with ELF executables so that Plan 9 can readily (*) join the platforms that can be used to cross-develop software. Now, the "go" toolchain is very close to the Plan 9 native toolchain, its most obvious difference lies in its default object format. Given the desirability of being able to generate ELF executables from within Plan 9 (the MIPS toolchain already does, but I had issues with that before now and the "go" toolchain diverges from that model somewhat, I believe from inspecting the source somewhat superficially) my hope is that the differences in the toolchains provided by the "go" development and Plan 9 can mostly be eliminated. Besides providing Plan 9 with a more modern toolchain, it also makes it more practical to port "go" to Plan 9 and it makes it possible to cross-develop "go" code on a Plan 9 platform; a small amount of effort in the direction of the MIPS architecture will also facilitate porting "go" to it. All developments I would be keen to contribute to, but lack the confidence more than the expertise to undertake on my own. ++L (*) There are mutual benefits: cross-compiling on a GNU platform to a Plan 9 target is too hard if one needs to produce Plan 9 native executables. Dave Hogan managed to twist GCC 3.0 (actually, binutils 2.11, if I remember right) to produce Plan 9 native executables, but I have failed dismally to reproduce his results on later versions of the GNU toolchain, it's just too dense for me. I have configured a cross-development toolchain under NetBSD that uses the Plan 9 libraries and syscall interface; it isn't yet possible for me to test whether the generated ELF executable actually would work, too many other chestnuts in the fire right now. Were this cross-development tool to be viable, one would use it to bootstrap the most recent stable version of GCC/G++, with results some 9fans might welcome.
