[go-nuts] Help! Can't get cgo to work

Raffaele Sena

at Jul 19, 2013 at 10:45 pm

I would try to run cgo directly with some debug flags enabled to see what
commands is running:

$ go tool cgo
usage: cgo -- [compiler options] file.go ...
   -cdefs=false: for bootstrap: write C definitions for C file to standard
output
   -debug-define=false: print relevant #defines
   -debug-gcc=false: print gcc invocations
   -dynimport="": if non-empty, print dynamic import data for that file
   -dynlinker=false: record dynamic linker information in dynimport mode
   -dynout="": write -dynobj output to this file
   -gccgo=false: generate files for use with gccgo
   -gccgopkgpath="": -fgo-pkgpath option used with gccgo
   -gccgoprefix="": -fgo-prefix option used with gccgo
   -godefs=false: for bootstrap: write Go definitions for C file to standard
output
   -import_runtime_cgo=true: import runtime/cgo in generated code
   -import_syscall=true: import syscall in generated code
   -objdir="": object directory

On Friday, July 19, 2013 1:37:27 PM UTC-7, [email protected] wrote:

I'm trying to build an interface for the Swiss Ephemeris package. So far,
I've got the original compiled to both a .a and a .so, and I've moved the
two header files I need into the same directory as the .go file. I've also
stuck the .a (but not the .so) into pkg/darwin_amd64.

Here's the source:

// swephint is the interface to the Swiss Ephemeris: see the Swiss
Ephemeris documentation
// for copyright information.

package swephint

/*

#cgo LDFLAGS: -llibswe

#import "swephexp.h"

*/
import "C"
import "unsafe"

func SetEphPath(path string) {
cpath := C.CString(path)
defer C.free(unsafe.Pointer(cpath))
C.swe_set_ephe_path(cpath)
}

This is an almost direct copy from the cgo article.

What's happening is:

jhrothjr:src johnroth$ go install swephint
# swephint
ld: library not found for -llibswe
collect2: ld returned 1 exit status

I've already tried using -L for the directory where the .a and .so were
originally compiled to. It also doesn't seem to make any difference whether
I say -llibswe or -llibswe.a

As you might guess, I'm a relative novice in unix-style development tools.

Any ideas? Thanks in advance

Thanks.

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.

reply | permalink

Johnroth1

at Jul 20, 2013 at 1:16 am

⇧

On Friday, July 19, 2013 4:45:04 PM UTC-6, Raffaele Sena wrote:
I would try to run cgo directly with some debug flags enabled to see what
commands is running:

$ go tool cgo
usage: cgo -- [compiler options] file.go ...
-cdefs=false: for bootstrap: write C definitions for C file to standard
output
-debug-define=false: print relevant #defines
-debug-gcc=false: print gcc invocations
-dynimport="": if non-empty, print dynamic import data for that file
-dynlinker=false: record dynamic linker information in dynimport mode
-dynout="": write -dynobj output to this file
-gccgo=false: generate files for use with gccgo
-gccgopkgpath="": -fgo-pkgpath option used with gccgo
-gccgoprefix="": -fgo-prefix option used with gccgo
-godefs=false: for bootstrap: write Go definitions for C file to
standard output
-import_runtime_cgo=true: import runtime/cgo in generated code
-import_syscall=true: import syscall in generated code
-objdir="": object directory

On Friday, July 19, 2013 1:37:27 PM UTC-7, [email protected] wrote:

I'm trying to build an interface for the Swiss Ephemeris package. So far,
I've got the original compiled to both a .a and a .so, and I've moved the
two header files I need into the same directory as the .go file. I've also
stuck the .a (but not the .so) into pkg/darwin_amd64.

Here's the source:

// swephint is the interface to the Swiss Ephemeris: see the Swiss
Ephemeris documentation
// for copyright information.

package swephint

/*

#cgo LDFLAGS: -llibswe

#import "swephexp.h"

*/
import "C"
import "unsafe"

func SetEphPath(path string) {
cpath := C.CString(path)
defer C.free(unsafe.Pointer(cpath))
C.swe_set_ephe_path(cpath)
}

This is an almost direct copy from the cgo article.

What's happening is:

jhrothjr:src johnroth$ go install swephint
# swephint
ld: library not found for -llibswe
collect2: ld returned 1 exit status

I've already tried using -L for the directory where the .a and .so were
originally compiled to. It also doesn't seem to make any difference whether
I say -llibswe or -llibswe.a

As you might guess, I'm a relative novice in unix-style development tools.

Any ideas? Thanks in advance

Thanks.

Thanks for the suggestion. After a lot of spelunking in the docs, I finally
got it to work. The problem was the #cgo declaration. It should have been:

#cgo LDFLAGS: -L(path to library) -lswe

It totally did not occur to me that ld would prefix what I wrote with
"lib". That's the kind of "help" that definitely evil.

Thanks again.

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.

reply | permalink

__kaveh__

at Nov 16, 2014 at 2:27 am

⇧

I can not get it to work (Windows 7 x64, MinGW x86, Go x86; LiteIDE); I get
this error:

.\swejpl.c:78:19: error: conflicting types for 'off_t'
    typedef __int64 off_t;
                    ^
In file included from c:\mingw\include\io.h:20:0,
                  from .\sweodef.h:86,
                  from .\swephexp.h:83,
                  from .\swejpl.c:71:
c:\mingw\include\sys\types.h:55:16: note: previous declaration of 'off_t'
was here
  typedef _off_t off_t;
                 ^

(as I understand I do not need to call `go tool cgo...` explicitly; it
would be called during `go build/go install` based on header comments;
right?)

On Saturday, July 20, 2013 5:46:29 AM UTC+4:30, [email protected] wrote:

On Friday, July 19, 2013 4:45:04 PM UTC-6, Raffaele Sena wrote:

I would try to run cgo directly with some debug flags enabled to see what
commands is running:

$ go tool cgo
usage: cgo -- [compiler options] file.go ...
-cdefs=false: for bootstrap: write C definitions for C file to standard
output
-debug-define=false: print relevant #defines
-debug-gcc=false: print gcc invocations
-dynimport="": if non-empty, print dynamic import data for that file
-dynlinker=false: record dynamic linker information in dynimport mode
-dynout="": write -dynobj output to this file
-gccgo=false: generate files for use with gccgo
-gccgopkgpath="": -fgo-pkgpath option used with gccgo
-gccgoprefix="": -fgo-prefix option used with gccgo
-godefs=false: for bootstrap: write Go definitions for C file to
standard output
-import_runtime_cgo=true: import runtime/cgo in generated code
-import_syscall=true: import syscall in generated code
-objdir="": object directory

On Friday, July 19, 2013 1:37:27 PM UTC-7, [email protected] wrote:

I'm trying to build an interface for the Swiss Ephemeris package. So
far, I've got the original compiled to both a .a and a .so, and I've moved
the two header files I need into the same directory as the .go file. I've
also stuck the .a (but not the .so) into pkg/darwin_amd64.

Here's the source:

// swephint is the interface to the Swiss Ephemeris: see the Swiss
Ephemeris documentation
// for copyright information.

package swephint

/*

#cgo LDFLAGS: -llibswe

#import "swephexp.h"

*/
import "C"
import "unsafe"

func SetEphPath(path string) {
cpath := C.CString(path)
defer C.free(unsafe.Pointer(cpath))
C.swe_set_ephe_path(cpath)
}

This is an almost direct copy from the cgo article.

What's happening is:

jhrothjr:src johnroth$ go install swephint
# swephint
ld: library not found for -llibswe
collect2: ld returned 1 exit status

I've already tried using -L for the directory where the .a and .so were
originally compiled to. It also doesn't seem to make any difference whether
I say -llibswe or -llibswe.a

As you might guess, I'm a relative novice in unix-style development
tools.

Any ideas? Thanks in advance

Thanks.

Thanks for the suggestion. After a lot of spelunking in the docs, I
finally got it to work. The problem was the #cgo declaration. It should
have been:

#cgo LDFLAGS: -L(path to library) -lswe

It totally did not occur to me that ld would prefix what I wrote with
"lib". That's the kind of "help" that definitely evil.

Thanks again.

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/d/optout.

reply | permalink

Lars Seipel

at Nov 16, 2014 at 3:10 am

⇧

On Sat, Nov 15, 2014 at 06:27:22PM -0800, __kaveh__ wrote:
I can not get it to work (Windows 7 x64, MinGW x86, Go x86; LiteIDE); I get
this error:

.\swejpl.c:78:19: error: conflicting types for 'off_t'
typedef __int64 off_t;

This doesn't look like a cgo issue but more like an issue with your C
code. It's correct that you don't need to call go tool cgo manually. Go
install will handle it. You need to give it valid C code, though.

Don't bother with cgo until you can compile your C code using the
C compiler.

As the compiler says, your code defines off_t multiple times using
conflicting types. One of those comes from a standard header
(sys/types.h) shipped with MinGW. Remove the typedef from your code or
make the definitions agree (is there something like _FILE_OFFSET_BITS=64
on windows?).

Is this swejpl.c file the one found here:
http://www.astro.com/ftp/swisseph/src/swejpl.c

It has the incriminated text on line 78, shoved behind an "#if MSDOS".
Find out if it belongs there and what is the appropriate thing to do for
your system.

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/d/optout.

reply | permalink

Johnroth1

at Nov 17, 2014 at 2:07 am

⇧

On Saturday, November 15, 2014 7:27:22 PM UTC-7, __kaveh__ wrote:
I can not get it to work (Windows 7 x64, MinGW x86, Go x86; LiteIDE); I
get this error:

.\swejpl.c:78:19: error: conflicting types for 'off_t'
typedef __int64 off_t;
^
In file included from c:\mingw\include\io.h:20:0,
from .\sweodef.h:86,
from .\swephexp.h:83,
from .\swejpl.c:71:
c:\mingw\include\sys\types.h:55:16: note: previous declaration of 'off_t'
was here
typedef _off_t off_t;
^

(as I understand I do not need to call `go tool cgo...` explicitly; it
would be called during `go build/go install` based on header comments;
right?)

The problem appears to be in sweodef.h, where it's attempting to do
autodetection of the compiler and system. It doesn't seem to understand
mingw, which I think is required to use cgo on Windows. (At least I think
that's the case, there's a lot about cgo that's still baffling me.)

If that's the issue, we need to take it back to the swephem mailing list.

HTH

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/d/optout.

reply | permalink

__kaveh__

at Nov 17, 2014 at 7:08 am

⇧

Thanks John; as Lars put it correctly it's a problem with gcc not cgo. But
since I am no C expert; I wished that this error could be something that
happens with cgo - which apparently is not the case. I am trying to get gcc
thing done first.

On Monday, November 17, 2014 5:37:17 AM UTC+3:30, [email protected] wrote:

On Saturday, November 15, 2014 7:27:22 PM UTC-7, __kaveh__ wrote:

I can not get it to work (Windows 7 x64, MinGW x86, Go x86; LiteIDE); I
get this error:

.\swejpl.c:78:19: error: conflicting types for 'off_t'
typedef __int64 off_t;
^
In file included from c:\mingw\include\io.h:20:0,
from .\sweodef.h:86,
from .\swephexp.h:83,
from .\swejpl.c:71:
c:\mingw\include\sys\types.h:55:16: note: previous declaration of 'off_t'
was here
typedef _off_t off_t;
^

(as I understand I do not need to call `go tool cgo...` explicitly; it
would be called during `go build/go install` based on header comments;
right?)

The problem appears to be in sweodef.h, where it's attempting to do
autodetection of the compiler and system. It doesn't seem to understand
mingw, which I think is required to use cgo on Windows. (At least I think
that's the case, there's a lot about cgo that's still baffling me.)

If that's the issue, we need to take it back to the swephem mailing list.

HTH

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/d/optout.

reply | permalink

group	golang-nuts @
categories	go
posted	Jul 19, '13 at 10:06p
active	Nov 17, '14 at 7:08a
posts	7
users	4
website	golang.org

responses	expanded	Hotkey: s
font	variable	Hotkey: f
user style	avatars	Hotkey: a

[go-nuts] Help! Can't get cgo to work

Search Discussions

Related Discussions

4 users in discussion