On Sun, Apr 03, 2011 at 11:20:25AM -0700, Rob Pike wrote: > > I'm not sure I follow. The 6c and 6g compilers in the Go distribution > are compiled with the local compiler, such as gcc on Linux and OS X. > I don't believe it's possible they have Plan 9-specific features in > their source. I can believe they would have problems compiling on > Plan 9, but that's the inverse problem. > On the contrary (if that makes sense), they have that nasty "#include <stdio.h>" that Erik referred to and Plan 9 is allergic to, as well as a number of nested #includes that trigger rebellion in the Plan 9 toolchain. And I don't have a 64-bit host to test them on.
But do not forget that I have a Plan 9 native toolchain that compiles a runnable copy of "hello.c", including printf() invocation. It's just too old to be useful. > Once 6c is built, it is used to build the Go runtime, so the source > and compiler should match perfectly. Plan 9 compiler issues should > not be relevant. > I haven't even considered using the toolchain for Plan 9 native because I can't track releases given the many changes required to silence the Plan 9 toolchain. And maybe some warnings can be overlooked, but I don't want to be the judge of that. Basically, I can't find an approach to submitting changes to the Go toolchain so it can run under Plan 9 that does not involve major surgery, nor can I separate the changes out in small parcels because testing is impractical. I'm hoping that things will eventually settle down and there will be resources to review extensive, if documentable changes. Not being able to back-port the Go toolchain to Plan 9 native seems defeatist. Now that a runtime is available and will hopefully receive extensive testing, it makes the exercise even more worthwhile. And if issues such as compatibility in function argument definitions can be resolved amicably between the GCC compiler and the Plan 9 toolchain, then things are really looking up. But, as I stated earlier, it requires the will on the Go side to retrofit changes for the sake of Plan 9, and that may be a problem. My failed efforts (possibly thoroughly misguided) to get l.h accepted with changes acceptable to the Plan 9 built-in pre-processor suggest that the Go developers have different objectives in mind. If this does not address Rob's concerns, then I'd like to ask for the question(s) to be phrased more clearly. And again, I think one ought to look at all the "Plan 9" favours out there: 9vx deserves effort, Plan9port could support Go better than the native environment, linuxemu would provide a useful testbench. Only GCC 3.0 in Plan 9 is almost certainly a dead end. ++L
