Generating Go code from C .h files

2,044 views
Skip to first unread message

Jonathan Pittman

unread,
Jul 22, 2012, 10:13:26 AM7/22/12
to golang-nuts
I have a .h file that contains a bunch of  "typedef", "typedef struct", "struct", and "#define" (i.e. constants, variables, structs).  Is there a simple tool that I can use to take a file like this and generate the equivalent Go code?  I am thinking of something along the lines of the mk{all,errors,syscall,sysnum} scripts in the src/pkg/syscall directory.

Jeff Hodges

unread,
Jul 22, 2012, 1:18:38 PM7/22/12
to Jonathan Pittman, golang-nuts
Just about everything you want comes from using SWIG. See
<http://www.swig.org/Doc2.0/Go.html> and
<http://golang.org/misc/swig/>. I'd recommend taking a swing with it,
first.

Unfortunately, unless the header files are straightforward and you
know their format ahead of time (like those perl scripts do since the
headers in question are de facto standards), there's no such thing as
a "simple" header parsing tool. C is just rather difficult to parse,
generically. SWIG is almost certainly what you want.

If you're really ambitious, you could probably make something work
with libclang. binet has
<http://go.pkgdoc.org/bitbucket.org/binet/go-clang/pkg/clang> but I
can't quite tell if it's fleshed out in the direction you want to take
it. Of course, using it would, you know, require more code to be
written and you'd probably have just a worse version of SWIG by the
end of it.

Archos

unread,
Jul 22, 2012, 1:56:14 PM7/22/12
to golan...@googlegroups.com

El domingo, 22 de julio de 2012 15:13:26 UTC+1, Jonathan escribió:
I have a .h file that contains a bunch of  "typedef", "typedef struct", "struct", and "#define" (i.e. constants, variables, structs).  Is there a simple tool that I can use to take a file like this and generate the equivalent Go code?  I am thinking of something along the lines of the mk{all,errors,syscall,sysnum} scripts in the src/pkg/syscall directory.
I'd built a program for it, so I can build fastly Go bindings from Go to C

https://github.com/kless/def2go

Mike Rosset

unread,
Jul 22, 2012, 2:05:50 PM7/22/12
to Jonathan Pittman, golang-nuts
On Sun, Jul 22, 2012 at 7:13 AM, Jonathan Pittman
<jonathan.m...@gmail.com> wrote:
You can use go tool cgo -godefs to help with this see.
$GOROOT/src/pkg/syscall/types_linux.go
your mileage my vary though.

Jeff Hodges

unread,
Jul 22, 2012, 2:09:58 PM7/22/12
to Mike Rosset, Jonathan Pittman, golang-nuts
Ugh, I totally forgot about this. Which is funny because
https://groups.google.com/forum/?fromgroups#!topic/golang-nuts/4wvIR5jEH0E

Jonathan Pittman

unread,
Jul 22, 2012, 5:48:48 PM7/22/12
to Jeff Hodges, Mike Rosset, golang-nuts
Thanks for the responses.  I was originally hoping that cgo -godefs would be the answer, but it seems to want a .go file, not a .h file.  Is there something I need to do in order to make cgo -godefs work?

Rémy Oudompheng

unread,
Jul 23, 2012, 1:36:19 AM7/23/12
to Jonathan Pittman, Jeff Hodges, Mike Rosset, golang-nuts
On Sun 22 July 2012 at 17:48 -0400, Jonathan Pittman wrote:
> Thanks for the responses. I was originally hoping that cgo -godefs would
> be the answer, but it seems to want a .go file, not a .h file. Is there
> something I need to do in order to make cgo -godefs work?

Yes, it may be lacking a bit of documentation cgo, -godefs does things like this:

$ cat elf.go
package elf

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

type Header32 C.Elf32_Ehdr
type Header64 C.Elf64_Ehdr

const (
Class32 = C.ELFCLASS32
Class64 = C.ELFCLASS64
)

$ go tool cgo -godefs elf.go
// Created by cgo -godefs - DO NOT EDIT
// cgo -godefs elf.go

package elf

type Header32 struct {
Ident [16]uint8
Type uint16
Machine uint16
Version uint32
Entry uint32
Phoff uint32
Shoff uint32
Flags uint32
Ehsize uint16
Phentsize uint16
Phnum uint16
Shentsize uint16
Shnum uint16
Shstrndx uint16
}
type Header64 struct {
Ident [16]uint8
Type uint16
Machine uint16
Version uint32
Entry uint64
Phoff uint64
Shoff uint64
Flags uint32
Ehsize uint16
Phentsize uint16
Phnum uint16
Shentsize uint16
Shnum uint16
Shstrndx uint16
}

const (
Class32 = 0x1
Class64 = 0x2
)

Sebastien Binet

unread,
Jul 23, 2012, 5:13:17 AM7/23/12
to Jeff Hodges, Jonathan Pittman, golang-nuts
On Sun, Jul 22, 2012 at 7:18 PM, Jeff Hodges <je...@somethingsimilar.com> wrote:
> Just about everything you want comes from using SWIG. See
> <http://www.swig.org/Doc2.0/Go.html> and
> <http://golang.org/misc/swig/>. I'd recommend taking a swing with it,
> first.
>
> Unfortunately, unless the header files are straightforward and you
> know their format ahead of time (like those perl scripts do since the
> headers in question are de facto standards), there's no such thing as
> a "simple" header parsing tool. C is just rather difficult to parse,
> generically. SWIG is almost certainly what you want.
>
> If you're really ambitious, you could probably make something work
> with libclang. binet has
> <http://go.pkgdoc.org/bitbucket.org/binet/go-clang/pkg/clang> but I
> can't quite tell if it's fleshed out in the direction you want to take
> it. Of course, using it would, you know, require more code to be
> written and you'd probably have just a worse version of SWIG by the
> end of it.

go-clang was indeed written with this use case in mind.
I am working on a tool to automatically wrap *any* C/C++ library.
we (in high energy physics) already have such a tool, called reflex,
which generates such kind of reflection informations (for automatic
I/O serialization and python bindings generation) based on gcc-xml.
my first version is based on such a scaffolding, but I tried to write
in such a way that it would be trivial to switch to another source of
reflection informations (gcc-xml -> CLang) as in HEP we're also
migrating away from gcc-xml to use CLang (and CLing, the C++
interpreter built on top of CLang).

it is not ready for public consumption yet.
but if you want to have a look:
https://github.com/sbinet/go-cxxdict

no doc, no readme :}

-s

Jonathan Pittman

unread,
Jul 23, 2012, 12:20:00 PM7/23/12
to remyoud...@gmail.com, Jeff Hodges, Mike Rosset, golang-nuts
Thanks Rémy.  That clears up a good bit that was not making much sense to me.  I suppose this is better than nothing, but it does seem awkward to have to write Go code just to get something generated.  Although, I somewhat understand the purpose of what is going on here (i.e. names are more Go like, but keep the structure intact from C).
Reply all
Reply to author
Forward
0 new messages