> The C compilers in the Go toolchain pass everything on the > stack and return the result in a register. > > The Go compilers pass everything on the stack including the > output parameters. No registers are involved in the calling > convention.
That isn't a big deal, in my case, because the language handled by the C compilers in the Go toolchain is the same as Plan 9 native C, so, within reason, I would expect the Go toolchain to compile the OpenLDAP programs successfully, it doesn't matter if they are not consistent with the Plan 9 native toolchain. I suppose this raises the first concrete question: how do I get the "go" tool to compile the OpenLDAP libraries (and possibly programs) in some sensible fashion? It would be distressing to have to increase the autoconf hell at this point. A partial answer to this would be preferable to a blunt "You should not be wanting to do this". Again, thanks for the contributions, the fog isn't visibly lifting yet, but the feeling's there :-) ++L PS: Note that even corrections of crossed wires have been extremely helpful. PPS: Eventually, there needs to be ONE Go + C + ASM toolchain. It may take years and a lot of TLC to produce, but any other outcome, with the possible exception that something will obsolete each of the above languages, is a frightening prospect in the long term. Let's keep that in mind and not contribute intentionally and unnecessarily to the divergence.
