FAQ
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 golang-nuts+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Search Discussions

  • 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, john...@gmail.com 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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • 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, john...@gmail.com 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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • __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, john...@gmail.com 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, john...@gmail.com 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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • 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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • 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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • __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, john...@gmail.com 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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedJul 19, '13 at 10:06p
activeNov 17, '14 at 7:08a
posts7
users4
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase