From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <6687527721a908cf83dbb33b10206092@proxima.alt.za>
To: 9fans@9fans.net
Date: Sat,  2 Feb 2013 17:52:39 +0200
From: lucio@proxima.alt.za
In-Reply-To: <20130202152419.GA30387@dinah>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: Re: [9fans] Go: CGO and Plan 9
Topicbox-Message-UUID: 1402bfee-ead8-11e9-9d60-3106f5b1d025

> 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.