16

I'm attempting to write some C bindings for the Go language, and have run into a sort of sticky situation when setting up the Cgo compilation in Windows. I have code that looks like the following:

// #cgo windows CFLAGS: -I C:/dev/extlibs/include/
// #cgo windows LDFLAGS: -lMyLib -L C:/dev/extlibs/lib/
// #include <mylib/mylib.h>
import "C"

which is allows me to avoid installing Dlls, libs, and header files directly into my C:\Windows directory, but doesn't allow for much flexibility when other developers are working with a different file system setup (they all need the libs to be in C:/dev/extlibs/...).

Is there a way I could referent an environment variable from within the code? Perhaps something along the lines of:

// #cgo windows CFLAGS: -I $EXTLIBS$/include/

Or is there another way that people solve this issue that I have missed? I've spent some time googling around on this subject and haven't seen much that has been useful, so any information and/or resources could be a real help!

Tyler
  • 21,762
  • 11
  • 61
  • 90
Chris Covert
  • 2,684
  • 3
  • 24
  • 31

2 Answers2

19

According to the docs for CGO:

When building, the CGO_CFLAGS, CGO_CPPFLAGS, CGO_CXXFLAGS and CGO_LDFLAGS environment variables are added to the flags derived from these directives. Package-specific flags should be set using the directives, not the environment variables, so that builds work in unmodified environments.

Using this knowledge, I have had success building a third-party package that wraps a C library so long as it provides it as a system package. The example I linked to:

package sdl

// #cgo LDFLAGS: -lSDL2
// #include <SDL2/SDL.h>
import "C"

Even though it specifies a system package for SDL2, and I have SDL2 installed in some non-system directory, I am able to still build this package using some of the environment variables I mentioned, such as in the following:

export SDL_PATH=/home/mark/where/I/installed/sdl
CGO_CFLAGS="-I$SDL_PATH/include" CGO_LDFLAGS="-L$SDL_PATH/lib" go build hello.go
LD_LIBRARY_PATH="$SDL_PATH/lib" ./hello

Of course, this is Linux, but you can probably use the same ideas in Windows.

Mark Hildreth
  • 42,023
  • 11
  • 120
  • 109
9

You could try using environment variables, the Gentoo Linux Wiki page on Safe C Flags has an example in the following format

CXXFLAGS="${CFLAGS}"

So you may be able to do something like

// #cgo windows CFLAGS: -I "${EXTLIBS}"/include/

but my syntax may be off, and that may be Makefile specific.

You could also try setting a CPATH environment variable which:

specifies a list of directories to be searched as if specified with -I, but after any paths given with -I options on the command line. This environment variable is used regardless of which language is being preprocessed.

The equivalent for -L is, I think, LIBRARY_PATH (Described at the CPATH link).

According to http://golang.org/cmd/cgo/ one sort of recommended way to get around this in a platform independant way is to use pkg-config.

// #cgo pkg-config: mylib otherlib

It's available for windows (http://ftp.gnome.org/pub/gnome/binaries/win32/dependencies/) and there's some more information on installing it at this question (How to install pkg config in windows?)

Other than that, put all the dependencies into a sub-directory of the go-code, use relative paths in your CFLAGS and LDFLAGS, and share the entire bundle with other developers.

Community
  • 1
  • 1
Intermernet
  • 18,604
  • 4
  • 49
  • 61
  • Those are some good ideas. I'll give them a try. FWIW, I use pk-config on darwin/linux, but it's always seemed a bit more trouble than its been worth on Windows in the past. – Chris Covert Jun 10 '13 at 17:05
  • @ChrisCovert Yes, It took me a while to sort out the dependencies on Win8 :-( Got it in the end though, that linked SO question has a few good links in the comments. – Intermernet Jun 11 '13 at 10:12
  • FWIW, I think I'm going to give pkg-config a try, and see if it works out a bit better than last time. Thanks for the resources! – Chris Covert Jun 12 '13 at 13:05