9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: Pavel Zholkover <paulzhol@gmail.com>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Subject: Re: [9fans] Go: CGO and Plan 9
Date: Fri,  1 Feb 2013 19:52:58 +0200	[thread overview]
Message-ID: <CAJdW5jc1Y8hvS5gtXQpTP4wp==G5ZL=khxpH87Xw=BBAHf-RVw@mail.gmail.com> (raw)
In-Reply-To: <631828b4eaee51d49ac685c47b6b3554@proxima.alt.za>

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



  reply	other threads:[~2013-02-01 17:52 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-30  4:41 lucio
2013-02-01 17:52 ` Pavel Zholkover [this message]
2013-02-02 14:28 ` Aram Hăvărneanu
2013-02-02 15:24   ` Anthony Martin
2013-02-02 15:52     ` lucio
2013-02-02 15:41   ` lucio

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAJdW5jc1Y8hvS5gtXQpTP4wp==G5ZL=khxpH87Xw=BBAHf-RVw@mail.gmail.com' \
    --to=paulzhol@gmail.com \
    --cc=9fans@9fans.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).