I had a go at getting go to run on Haiku (pun intended). Using hrev52346 and a slight modification to the existing golang 1.3 port recipe (remove -Werror compiler flags only), I can get Go compiled. See the below image:-
The tests themselves don’t all run, but I can run a simple hello world app as per the image.
Versions above go 1.4 require a go compiler rather than C, so you have to bootstrap from another platform apparently. Not sure how best to proceed… is a 1.3/1.4 recipe any good these days?
The Go 1.3 port isn’t useful for bootstrapping, you will need Go 1.4 and above for that.
I’ve done a port of Go 1.4.3 for x86_64 which is almost able to compile newer versions of Go, over at HaikuPorts. Its still a work in progress and you can have a try at bootstrapping newer versions of Go with it.
Yeah I got 1.3 compiling fine with a couple of little tweaks to the build. The next step is to get 1.4 compiled using 1.3. Once that is done, you can compile the latest version 1.5.
I’m hoping to get some time to work on this soon, but it depends on what’s going on at work the next few weeks.
I have 1.3 working (also, checking the tests, as some fail) and go-getting packages. that’s almost done with the fixes (basically disabling the -werror flag).
1.4 seems to be a binary version too, so i dont think you can bootstrap it with 1.3 (tries to compile again the dist, iirc).
Unfortunately, the old source has ‘haiku’ as goos internal system, so to get further versions (1.5+) to “compile” you need to patch the new version files to have “haiku” (and ‘Hhaiku’) present, and also patch all the go-file sources that include “+build” tag to also build for haiku (whenever it should be).
What i mean is that i’m stuck on the 1.5 compilation at net/url package (probably some code not been ported or set ok in the 1.3 part, or the patched 1.5 files).
Not sure about the viability of it in the future, unless it’s done ok and patched in upstream source too (so golang has flags for haiku in official repo for future… future… future versions).
It might be easier to port gccgo, since it’s part of GCC, which we already have. Wouldn’t be the same thing, of course, but maybe it could help with porting the official Go SDK?
