On Dec 3, 2013, at 1:31 AM, lu...@proxima.alt.za wrote: > > I am totally with you on this one. But the macros are in <bio.h>, so > we may be able to avoid them. They are obscene and trigger many > annoying warnings.
See https://codereview.appspot.com/15750047 as it gets around the issue w/o using the current go supplied <bio.h> but the Plan 9 system supplied bio.h (+ a little mingling in of the additions to $GOROOT/include/plan9). I’m still not completely satisfied, but once I figure out cmd/dist internals a little more then the file I’ve currently dropped in $GOROOT/src/lib9/bio_plan9.c can be moved to $GOROOT/src/libbio and just compiled storing the $O in $GOROOT/pkg/obj/plan9_$objtype and linked in addition to Plan 9’s /$objtype/lib/libbio.a. I use: cmd/8g: work around 64-bit bug in 8c for Plan 9 https://codereview.appspot.com/14521056 runtime: do not use memmove in the Plan 9 signal handler https://codereview.appspot.com/34640045 libbio mod (not full replacement, just funcs and macros) https://codereview.appspot.com/15750047 libbio to build go for 386 off a standard sources release with my ape patch and an install of python 2.7.5 + hg. There are still issues in trying to get amd64 working that require changes to cmd/dist source and some of the pkg/runtime. I’m close, but need to eliminate some X11 distractions before really finishing it up. There is one little bit I’d also like to figure out how to work around: the install location of go & gofmt: the go_bootstrap puts those binaries into $GOROOT/bin even though the actual $objtype targets get installed into $GOROOT/pkg/*$objtype. It’s a small mess, but still one that makes multi-architecture file servers a little awkward (no nearly as awkward as Python’s attempt at cross-compilation). -jas
