Calling Go Functions from Other Languages

Starting with version 1.5, the Go compiler introduced support for several build modes via the -buildmode flag. Known as the Go Execution Modes, these build modes extended the go tool to compile Go packages into several formats including Go archives, Go shared libraries, C archives, C shared libraries, and (introduced in 1.8) Go dynamic plugins.

This post is about compiling Go packages into C shared libraries. With this build mode, the compiler outputs a standard shared object binary file (.so) exposing Go functions as a C-style APIs. Here we discuss how to create Go libraries that can be called from C, Python, Ruby, Node, and Java.

All source code for this writeup is available on GitHub.

The Go Code

Assume that we have written an awesome Go library that we want to make available to other languages. There are four requirements to follow before compiling the code into a shared library:

  • The package must be amain package. The compiler will build the package and all of its dependencies into a single shared object binary.
  • The source must import the pseudo-package “C”.
  • Use the //export comment to annotate functions you wish to make accessible to other languages.
  • An empty main function must be declared.

The following Go source exports functions Add, Cosine, Sort, and Log. Admittedly, the awesome package is not that impressive as you will see. However, its diverse function signatures will help us explore type mapping implications.

package main
import "C"
import (
var count int
var mtx sync.Mutex
//export Add
func Add(a, b int) int { return a + b }
//export Cosine
func Cosine(x float64) float64 { return math.Cos(x) }
//export Sort
func Sort(vals []int) { sort.Ints(vals) }
//export Log
func Log(msg string) int {
defer mtx.Unlock()
return count
func main() {}
// See awesome.go GitHub

The package is compiled using the -buildmode=c-shared build flag to create the shared object binary:

go build -o -buildmode=c-shared awesome.go

Upon completion, the compiler outputs two files:awesome.h, a C header file and, the shared object file, shown below:

-rw-rw-r —    1362 Feb 11 07:59 awesome.h
-rw-rw-r — 1997880 Feb 11 07:59

Notice that the .so file is around 2 Mb, relatively large for such a small library. This is because the entire Go runtime machinery goodness and dependent packages are crammed into a single shared object binary (similar to compiling a single static executable).

The header file

The header file defines C types mapped to Go compatible types (using cgo semantics, not discussed here).

/* Created by “go tool cgo” — DO NOT EDIT. */
typedef long long GoInt64;
typedef GoInt64 GoInt;
typedef struct { const char *p; GoInt n; } GoString;
typedef struct { void *data; GoInt len; GoInt cap; } GoSlice;
extern GoInt Add(GoInt p0, GoInt p1);
extern GoFloat64 Cosine(GoFloat64 p0);

The shared object file

The other file generated by the compiler is a 64-bit ELF shared object binary file. We can verify its information using the file command.

$> file ELF 64-bit LSB shared object, x86–64, version 1 (SYSV), dynamically linked, BuildID[sha1]=1fcf29a2779a335371f17219fffbdc47b2ed378a, not stripped

Using the nm and grep commands, we can inspect that our Go functions got exported.

$> nm | grep -e "T Add" -e "T Cosine" -e "T Sort" -e "T Log"
00000000000d0db0 T Add
00000000000d0e30 T Cosine
00000000000d0f30 T Log
00000000000d0eb0 T Sort

Next, we will explore several examples showing how to invoke the exported functions from other languages.

From C

There are two ways to use the shared object library to call Go functions from C. First, the code can be statically bound with the shared library during compilation, but dynamically linked at runtime. Or, have the Go function symbols be dynamically loaded and bound at runtime.

Dynamically linked

In this approach, we use the header file to statically reference types and functions exported in the shared object file. The code is simple and clean as shown below (some print statements are omitted):

#include <stdio.h>
#include "awesome.h"
int main() {
GoInt a = 12;
GoInt b = 99;
printf("awesome.Add(12,99) = %d\n", Add(a, b));
printf("awesome.Cosine(1) = %f\n", (float)(Cosine(1.0)));
    GoInt data[6] = {77, 12, 5, 99, 28, 23};
GoSlice nums = {data, 6, 6};
for (int i = 0; i < 6; i++){
printf("%d,", ((GoInt *)[i]);
    GoString msg = {"Hello from C!", 13};
// See client1.c on GitHub

Next the code is compiled, specifying the shared object library:

$> gcc -o client client1.c ./

When executed, the binary links to the library producing the output below.

$> ./client
awesome.Add(12,99) = 111
awesome.Cosine(1) = 0.540302
awesome.Sort(77,12,5,99,28,23): 5,12,23,28,77,99,
Hello from C!

Dynamically Loaded

In this approach, the C code uses the dynamic link loader library ( to dynamically load and bind to the exported symbols. It uses functions defined in dhfcn.h such as dlopen to open the library file, dlsym to look up a symbol, dlerror to retrieve errors, and dlclose to close the shared library file.

As highlighted below, this C version is lengthier, but does the same thing as before.

#include <stdlib.h>
#include <stdio.h>
#include <dlfcn.h>
typedef long long go_int;
typedef double go_float64;
typedef struct{void *arr; go_int len; go_int cap} go_slice;
typedef struct{const char *p; go_int len;} go_str;
int main(int argc, char **argv) {
void *handle;
char *error;
  handle = dlopen ("./", RTLD_LAZY);
if (!handle) {
fputs (dlerror(), stderr);
  go_int (*add)(go_int, go_int) = dlsym(handle, "Add");
if ((error = dlerror()) != NULL) {
fputs(error, stderr);
go_int sum = (*add)(12, 99);
printf("awesome.Add(12, 99) = %d\n", sum);

go_float64 (*cosine)(go_float64) = dlsym(handle, "Cosine");
go_float64 cos = (*cosine)(1.0);

void (*sort)(go_slice) = dlsym(handle, "Sort");
go_int data[5] = {44,23,7,66,2};
go_slice nums = {data, 5, 5};

go_int (*log)(go_str) = dlsym(handle, "Log");
go_str msg = {"Hello from C!", 13};

// See client2.c on GitHub

In this version, the code uses its own defined C types: go_int, go_float, go_slice, and go_str (for illustrative purpose, awesome.h could have been used). Function dlsym loads the function symbols and assign them to their respective function pointers. Next, the code can be compiled, linking it with the dl library (not the as follows:

$> gcc -o client client2.c -ldl

When the code is executed, the C binary loads and links to shared library producing the following output:

$> ./client
awesome.Add(12, 99) = 111
awesome.Cosine(1) = 0.540302
awesome.Sort(44,23,7,66,2): 2,7,23,44,66,
Hello from C!

From Python

In Python things get a little easier. The ctypes foreign function library is used to call the exported Go functions as shown in the following snippet (some print statements are omitted).

from ctypes import *
lib = cdll.LoadLibrary("./")
lib.Add.argtypes = [c_longlong, c_longlong]
print "awesome.Add(12,99) = %d" % lib.Add(12,99)
lib.Cosine.argtypes = [c_double]
lib.Cosine.restype = c_double
cos = lib.Cosine(1)
print "awesome.Cosine(1) = %f" % cos
class GoSlice(Structure):
_fields_ = [("data", POINTER(c_void_p)),
("len", c_longlong), ("cap", c_longlong)]
nums = GoSlice((c_void_p * 5)(74, 4, 122, 9, 12), 5, 5)
lib.Sort.argtypes = [GoSlice]
lib.Sort.restype = None
class GoString(Structure):
_fields_ = [("p", c_char_p), ("n", c_longlong)]
lib.Log.argtypes = [GoString]
msg = GoString(b"Hello Python!", 13)
# See on GitHub

The lib variable represents the loaded symbols from the shared object file. Python classes GoString and GoSlice map to their respective C struct types. When the Python code is executed, it calls the Go functions in the shared object producing the following output:

$> python
awesome.Add(12,99) = 111
awesome.Cosine(1) = 0.540302
awesome.Sort(74,4,122,9,12) = [ 4 9 12 74 122 ]
Hello Python!

From Ruby

Calling Go functions from Ruby follows a similar pattern as above using the FFI gem to dynamically load and call exported Go functions as shown in the following snippet.

require 'ffi'
module Awesome
extend FFI::Library
  ffi_lib './'
  class GoSlice < FFI::Struct
layout :data, :pointer,
:len, :long_long,
:cap, :long_long
  class GoString < FFI::Struct
layout :p, :pointer,
:len, :long_long
  attach_function :Add, [:long_long, :long_long], :long_long
attach_function :Cosine, [:double], :double
attach_function :Sort, [GoSlice.by_value], :void
attach_function :Log, [GoString.by_value], :int

print "awesome.Add(12, 99) = ", Awesome.Add(12, 99), "\n"
print "awesome.Cosine(1) = ", Awesome.Cosine(1), "\n"
nums = [92,101,3,44,7]
ptr = :long_long, nums.size
ptr.write_array_of_long_long nums
slice =
slice[:data] = ptr
slice[:len] = nums.size
slice[:cap] = nums.size
msg = "Hello Ruby!"
gostr =
gostr[:p] = FFI::MemoryPointer.from_string(msg)
gostr[:len] = msg.size
# See client.rb on GitHub

In Ruby, the FFI::library class is extended to declare a class that loads the exported symbols. Classes GoSlice and GoString map to their respective C structs. When we run the code it calls the exported Go functions as shown below:

$> ruby client.rb
awesome.Add(12, 99) = 111
awesome.Cosine(1) = 0.5403023058681398
awesome.Sort([92, 101, 3, 44, 7]) = [3, 7, 44, 92, 101]
Hello Ruby!

From Node

Node uses a foreign function library called node-ffi (and a other dependent libraries) to dynamically load and call exported Go functions as highlighted the following snippet:

var ref = require("ref");
var ffi = require("ffi");
var Struct = require("ref-struct")
var ArrayType = require("ref-array")
var LongArray = ArrayType(ref.types.longlong);
var GoSlice = Struct({
data: LongArray,
len: "longlong",
cap: "longlong"
var GoString = Struct({
p: "string",
n: "longlong"
var awesome = ffi.Library("./", {
Add: ["longlong", ["longlong", "longlong"]],
Cosine: ["double", ["double"]],
Sort: ["void", [GoSlice]],
Log: ["longlong", [GoString]]
console.log("awesome.Add(12, 99) = ", awesome.Add(12, 99));
console.log("awesome.Cosine(1) = ", awesome.Cosine(1));
nums = LongArray([12,54,0,423,9]);
var slice = new GoSlice();
slice["data"] = nums;
slice["len"] = 5;
slice["cap"] = 5;
str = new GoString();
str["p"] = "Hello Node!";
str["n"] = 11;
// See client.js on GitHub

The ffi object manages the loaded symbols from the shared library . The Node Sturct object is used to create GoSlice and GoString to map to their respective C structs. When we run the code it calls the exported Go functions as shown below:

awesome.Add(12, 99) =  111
awesome.Cosine(1) = 0.5403023058681398
awesome.Sort([12,54,9,423,9] = [ 0, 9, 12, 54, 423 ]
Hello Node!

From Java

To call the exported Go functions from Java, the Java Native Access project, or JNA, is used to make the programming easier as shown in the following code snippet (with some statements omitted or abbreviated):

import com.sun.jna.*;
public class Client {
public interface Awesome extends Library {
public class GoSlice extends Structure {
public Pointer data;
public long len;
public long cap;

public class GoString extends Structure {
public String p;
public long n;
public long Add(long a, long b);
public double Cosine(double val);
public void Sort(GoSlice.ByValue vals);
public long Log(GoString.ByValue str);
  static public void main(String argv[]) {
Awesome awesome = (Awesome) Native.loadLibrary(
"./", Awesome.class);
    System.out.printf(... awesome.Add(12, 99));
System.out.printf(... awesome.Cosine(1.0));
    long[] nums = new long[]{53,11,5,2,88};
Memory arr = new Memory(... Native.getNativeSize(Long.TYPE));
Awesome.GoSlice.ByValue slice = new Awesome.GoSlice.ByValue(); = arr;
slice.len = nums.length;
slice.cap = nums.length;
    Awesome.GoString.ByValue str = new Awesome.GoString.ByValue();
str.p = "Hello Java!";
str.n = str.p.length();
System.out.printf(... awesome.Log(str));
// See on GitHub

The Java interface Awesome represents the symbols loaded from the shared library file. Classes GoSlice and GoString map to their respective C struct representations. When the code is compiled and run, it calls the exported Go functions as shown below:

$> javac -cp jna.jar
$> java -cp .:jna.jar Client
awesome.Add(12, 99) = 111
awesome.Cosine(1.0) = 0.5403023058681398
awesome.Sort(53,11,5,2,88) = [2 5 11 53 88 ]
Hello Java!


This post showed how to create a Go library that can be used from other languages. By compiling their Go packages into C-style shared libraries, Go programmers can easily make their projects work with C, Python, Ruby, Node, Java, etc. using in-process integration of shared object binaries. So, next time you create that killer API in Go, remember to shared with non-Go developers.

As always, if you find this writeup useful, please let me know by clicking on the icon to recommend this post.

Also, don’t forget to checkout my book on Go, titled Learning Go Programming from Packt Publishing.