CGO Help

141 views
Skip to first unread message

Brian Ketelsen

unread,
Oct 31, 2011, 3:17:17 PM10/31/11
to golang-nuts
Howdy Gophers, Sorry for creating such a long email, but I'm going to paste everything in here -- history has shown that the details excluded are the important ones.

I've got a C library that I'm trying to wrap with a Go library. The C library lives at /dqs/libmdAddr.so and is 64bit as shown here:

/dqs/libmdAddr.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped

My Go library looks like this:

package address

/*
#cgo CFLAGS: -g -O -Wall -pthread -I/dqs
#cgo LDFLAGS: -L/dqs -Wl,-rpath,/dqs -lmdAddr -lpthread

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

#include "mdAddr.h"
#define DATAPATH "/dqs"

mdAddr hAddrLib;

void address(){
//REALLY BIG SNIP HERE
}
*/
import "C"

func GetAddress(){
C.address()

}

When I make with a standard cog make file:
include $(GOROOT)/src/Make.inc

TARG=address
CGOFILES=\
goaosample.go\

include $(GOROOT)/src/Make.pkg

I get a library in my pkg directory called "address.a" as I would expect. Here's the output of that making:

[bketelsen@myhost cgo]$ make
CGOPKGPATH= cgo -- goaosample.go
touch _obj/_cgo_run
6g -o _go_.6 _obj/goaosample.cgo1.go _obj/_cgo_gotypes.go
6c -FVw -I/export/home/bketelsen/go/pkg/linux_amd64 -I . -o "_cgo_defun.6" _obj/_cgo_defun.c
gcc -m64 -I . -g -fPIC -O2 -o _cgo_main.o -c -g -O -Wall -pthread -I/dqs _obj/_cgo_main.c
gcc -m64 -I . -g -fPIC -O2 -o goaosample.cgo2.o -c -g -O -Wall -pthread -I/dqs _obj/goaosample.cgo2.c
goaosample.go: In function '_cgo_14160c338f51_Cfunc_address':
goaosample.go:138: warning: unused variable 'a'
gcc -m64 -I . -g -fPIC -O2 -o _cgo_export.o -c -g -O -Wall -pthread -I/dqs _obj/_cgo_export.c
gcc -m64 -g -fPIC -O2 -o _cgo1_.o _cgo_main.o goaosample.cgo2.o _cgo_export.o -L/dqs -Wl,-rpath,/dqs -lmdAddr -lpthread
cgo -dynimport _cgo1_.o >_obj/_cgo_import.c_ && mv -f _obj/_cgo_import.c_ _obj/_cgo_import.c
6c -FVw -I . -o "_cgo_import.6" _obj/_cgo_import.c
rm -f _obj/address.a
gopack grc _obj/address.a _go_.6 _cgo_defun.6 _cgo_import.6 goaosample.cgo2.o _cgo_export.o

That all looks good (I guess!) But when I try to run a program that has an import of that package, I get an error about being able to locate the .so linked in the Go library:

./6.out: error while loading shared libraries: libmdAddr.so: cannot open shared object file: No such file or directory

Here's that source:
package main

import (
"address"
)

func main(){
address.GetAddress()
}


Where am I going wrong? When I built the command line app I just used 6g and 6l as I usually would, no special linking, and I got no errors from 6g/6l.

All help and advice appreciated!

Brian


Brian Ketelsen

unread,
Oct 31, 2011, 3:23:21 PM10/31/11
to golang-nuts
Just an update, I exported:
LD_LIBRARY_PATH=/dqs
before running my test app and it worked. How can I remove that requirement? I thought that's what I was doing with the LDFLAGS in my CGO directives.

Thanks!

Brian

Ian Lance Taylor

unread,
Oct 31, 2011, 4:20:45 PM10/31/11
to Brian Ketelsen, golang-nuts
Brian Ketelsen <bket...@gmail.com> writes:

> Just an update, I exported:
> LD_LIBRARY_PATH=/dqs
> before running my test app and it worked. How can I remove that requirement? I thought that's what I was doing with the LDFLAGS in my CGO directives.

You need to pass the equivalent of the -rpath option to 6l. In the
Makefile which builds your executable, try setting

LDIMPORTS = -r /dqs

Ian

Brian Ketelsen

unread,
Oct 31, 2011, 7:59:41 PM10/31/11
to Ian Lance Taylor, golang-nuts

Beautiful. Thank you for the assistance. In the post makefile world where only the goinstall replacement exists, will there be a command line parameter?

Best,
Brian

Russ Cox

unread,
Nov 1, 2011, 12:58:09 AM11/1/11
to Brian Ketelsen, Ian Lance Taylor, golang-nuts
On Mon, Oct 31, 2011 at 19:59, Brian Ketelsen <bket...@gmail.com> wrote:
> Beautiful.  Thank you for the assistance.  In the post makefile
> world where only the goinstall replacement exists, will there be
> a command line parameter?

No. Please file an issue. I thought cgo pulled the rpath
information out from the LDFLAGS, but clearly it does not.

Russ

Reply all
Reply to author
Forward
0 new messages