>> PS: I still can't link an executable with the version of 8l from the >> Go toolchain that I built under Plan 9, but I'm hoping to get there >> soon. > > It's of some consolation to me that I see exactly the same results > under Ubuntu, so that particular problem isn't in the 8l executable > created for Plan 9. I may have something exciting to report on this > issue within the day. > Having rebuilt a copy of runtime.a as well as of "hell-o.8", I now have an executable created from "hell-o.go" that runs sucessfully under Plan 9 after having been linked with an "8l" from the Go toolchain built entirely under Plan 9. If I were any good with picture I'd try to make the above easier to visualise.
It seems to me that, contrary to Pavel's careful statement, '8g" itself is not agnostic regarding the "GOOS=plan9" environment variable: I'll stick out my neck and claim without sufficient investigation that (a) the object code is flagged with the architecture name and (b) that the module functions init() and main() are labelled with a period (main.main) versus with the Go-special mid-line dot (middle-dot or UTF-00b7 as in "main·main") in Linux and Plan 9 respectively. I would like to upload the modified Go toolchain source code I used to produce "8l" under Plan 9 to "sources", but I'll wait to find that there is some interest as well as suggestions on the best approach to submit these sources to review and testing by others. I have everything at hand to reproduce these sources, but some help will be needed to tie up any lose ends from outside the Go toolchain sources. And, once again, many thanks to Pavel (and the Go Authors, of course) for making this possible and assisting with it. My next task will be to make similar changes to "8a", "8c" and "8g" to complete the series of 386 tools. But I also want to submit the changes in "src/cmd/8l" and "src/cmd/ld" to the Go Authors for inclusion in future releases, but that isn't going to be a trouble-free request, the changes have been rather pervasive. ++L
