From mboxrd@z Thu Jan  1 00:00:00 1970
MIME-Version: 1.0
In-Reply-To: <631828b4eaee51d49ac685c47b6b3554@proxima.alt.za>
References: <631828b4eaee51d49ac685c47b6b3554@proxima.alt.za>
Date: Fri,  1 Feb 2013 19:52:58 +0200
Message-ID: <CAJdW5jc1Y8hvS5gtXQpTP4wp==G5ZL=khxpH87Xw=BBAHf-RVw@mail.gmail.com>
From: Pavel Zholkover <paulzhol@gmail.com>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [9fans] Go: CGO and Plan 9
Topicbox-Message-UUID: 1338b096-ead8-11e9-9d60-3106f5b1d025

CGO will generate C code stubs that require gcc to compile.
The gcc generated executable (_cgo_.o in the example bellow) is then
parsed for it's dwarf debug info
(I think) to get import the names and dso's of imported symbols.
Later, when you build an executable using the cgo'd package; 6l will
generate a dynamically linked executable making
the dynamic linker load/mmap the needed libraries (regular go
executables are statically linked, and there is their great value
in my opinion).

I think that if you really want LDAP, you'd either implement it
natively in Go, or massage the plan9 ported version of OpenLDAP
to build using the Go C compilers as part of a Go ldap.a library.

Attached is a simple cgo build example with verbose output from the go tool.
/tmp/test$ cat cgo_atoi.go
package cgo_atoi

// #include <stdlib.h>
import "C"

func Atoi(s string) int {
n, _ := C.atoi(C.CString(s))
        return int(n)
}

/tmp/test$ go build -v -x -work
WORK=/tmp/go-build967270508
_/tmp/test
mkdir -p $WORK/_/tmp/test/_obj/
cd /tmp/test
/usr/local/go/pkg/tool/linux_amd64/cgo -objdir $WORK/_/tmp/test/_obj/
-- -I $WORK/_/tmp/test/_obj/ cgo_atoi.go
/usr/local/go/pkg/tool/linux_amd64/6c -FVw -I $WORK/_/tmp/test/_obj/
-I /usr/local/go/pkg/linux_amd64 -o $WORK/_/tmp/test/_obj/_cgo_defun.6
-DGOOS_linux -DGOARCH_amd64 $WORK/_/tmp/test/_obj/_cgo_defun.c
gcc -I . -g -O2 -fPIC -m64 -pthread -I $WORK/_/tmp/test/_obj/ -o
$WORK/_/tmp/test/_obj/_cgo_main.o -c $WORK/_/tmp/test/_obj/_cgo_main.c
gcc -I . -g -O2 -fPIC -m64 -pthread -I $WORK/_/tmp/test/_obj/ -o
$WORK/_/tmp/test/_obj/_cgo_export.o -c
$WORK/_/tmp/test/_obj/_cgo_export.c
gcc -I . -g -O2 -fPIC -m64 -pthread -I $WORK/_/tmp/test/_obj/ -o
$WORK/_/tmp/test/_obj/cgo_atoi.cgo2.o -c
$WORK/_/tmp/test/_obj/cgo_atoi.cgo2.c
gcc -I . -g -O2 -fPIC -m64 -pthread -o $WORK/_/tmp/test/_obj/_cgo_.o
$WORK/_/tmp/test/_obj/_cgo_main.o $WORK/_/tmp/test/_obj/_cgo_export.o
$WORK/_/tmp/test/_obj/cgo_atoi.cgo2.o
/usr/local/go/pkg/tool/linux_amd64/cgo -objdir $WORK/_/tmp/test/_obj/
-dynimport $WORK/_/tmp/test/_obj/_cgo_.o -dynout
$WORK/_/tmp/test/_obj/_cgo_import.c
/usr/local/go/pkg/tool/linux_amd64/6c -FVw -I $WORK/_/tmp/test/_obj/
-I /usr/local/go/pkg/linux_amd64 -o
$WORK/_/tmp/test/_obj/_cgo_import.6 -DGOOS_linux -DGOARCH_amd64
$WORK/_/tmp/test/_obj/_cgo_import.c
/usr/local/go/pkg/tool/linux_amd64/6g -o $WORK/_/tmp/test/_obj/_go_.6
-p _/tmp/test -D _/tmp/test -I $WORK
$WORK/_/tmp/test/_obj/_cgo_gotypes.go
$WORK/_/tmp/test/_obj/cgo_atoi.cgo1.go
/usr/local/go/pkg/tool/linux_amd64/pack grcP $WORK $WORK/_/tmp/test.a
$WORK/_/tmp/test/_obj/_go_.6 $WORK/_/tmp/test/_obj/_cgo_import.6
$WORK/_/tmp/test/_obj/_cgo_defun.6 $WORK/_/tmp/test/_obj/_cgo_export.o
$WORK/_/tmp/test/_obj/cgo_atoi.cgo2.o

- Pavel

On Wed, Jan 30, 2013 at 6:41 AM,  <lucio@proxima.alt.za> wrote:
> I need some help getting my mind around what should be a simple issue:
> how to connect Go with Plan 9's "native" toolchain.
>
> To be more specific, I have a port of the OpenLDAP library for Plan 9
> that works quite adequately and I would like to access it from GO. I
> guess this is true of any similar library ported using APE.  It seems
> to me that because Go can connect to native C libraries and because in
> Plan 9 the calling conventions are in fact identical, there ought to
> be an easy way to do it, but I don't realy understand what's involved.
>
> I suspect that the Go builder would have to be enhanced to deal with
> this, while at the same time I wonder if the C compiler and assembler
> should be used in a Go APE-like environment.  Whatever, I need help
> thinking this through, can anyone assist?
>
> ++L
>
> PS: I'd like the answer to be portable outside of Plan 9 (in p9p, to
> be exact), but that isn't essential.
>
>