Take the 2-minute tour ×

I'm trying to use an external C library with my Go program.

I have tried the following:

package cgoexample

#include <stdio.h>
#include <stdlib.h>

#cgo CFLAGS: -I/Users/me/somelib/include 
#cgo LDFLAGS: /Users/me/somelib/libhello.a
#include "stinger.h"
void myprint(char* s) {
        printf("%s", s);
import "C"

import "unsafe"
//... more here

In the /Users/me/somelib/include there is the .h file and in libhello.a there is the .o file (I checked using the ar command) that has the defined functions that are in the .h file.

It seems that the .h files are being linked OK, but it doesn't look like the archive file is being linked. I keep getting these:

warning: 'some_method_in_my_h_file" declared 'static' but never defined

And these warnings are being treated as errors. Regardless, they should be implemented in the archive file, so I'm confused what I'm doing wrong here.

When I run go build and gun run.

I have a feeling my #cgo command is invalid (I'm not C expert),

share|improve this question
can you add the functions definitions/declarations ? if thoses are declared are static, they should be defined and use in the file where they declared. static on a function definition tells the compiler to do not export your function outside the file. –  tomahh Sep 5 '13 at 17:59

1 Answer 1

Right, it doesn't work with ar object archives (*.a). There are two things you can do:

  • Link it in as a shared library (-lfoo in LDFLAGS, with libfoo.so in the library search path)

  • Put the *.c files themselves within the Go package directory, so that go build builds and links them in

If you're willing to go out of the standard go build behavior, though, you can unpack the *.a file into the individual object files, and then mimic the behavior of go build and cgo by hand.

For example, if you build a trivial cgo sample package with the -x option, you should see output similar to this:

% go build -x
.../cgo (...) sample.go
gcc -I . -g (...) -o $WORK/.../_obj/sample.o -c ./sample.c
gcc -I . -g (...) -o $WORK/.../_obj/_all.o (...) $WORK/.../_obj/sample.o
.../pack grcP $WORK $WORK/.../sample.a (...) .../_obj/_all.o
cd .
.../6l -o $WORK/.../a.out (...) $WORK/.../sample.a

So you can see that the individual *.c files are being compiled by gcc, packed together into a Go-specific ar archive, and then linked by 6l. You can do these steps by hand as well, if for some reason you really cannot put the *.c files in the package directory and let go build handle them for you (which would be a lot simpler and give people the chance of go geting your package).

share|improve this answer
i actually have a list of .o files in the same directory that made up the .a file. Is there a way for me to link all of them? –  K2xL Sep 5 '13 at 20:25
It is possible. I'll answer above to get more space. –  Gustavo Niemeyer Sep 5 '13 at 20:40
When you say package directory... I put them in pkg directory but it doesn't seem to be listing them when I use -x. Does my pkg directory need to be in a go path or go env or something? –  K2xL Sep 5 '13 at 21:17
btw, i managed to get the errors to go away (adjusted the LDFLAGS a bit). Problem I get now is a segmentation violation whenever I try and call any of the methods in the library :-( –  K2xL Sep 5 '13 at 21:19
The output shown is part of what go build -x generates while running inside the directory of a Go package that uses cgo. –  Gustavo Niemeyer Sep 5 '13 at 22:05

Your Answer


