Got it, thanks!
Scott Cotton ezt írta (időpont: 2018. okt. 1., H, 11:11):
>
> Hi,
>
> My use case is very very particular and unlikely to be related to most cgo
> use cases.
>
> The use case requires that there is no C calling of Go. the requirements
> arise from a special set of
Hi,
My use case is very very particular and unlikely to be related to most cgo
use cases.
The use case requires that there is no C calling of Go. the requirements
arise from a special set of circumstances, including
1. if C calls Go, then it is on a thread created in C
2. the thread above and
Sorry, I don't understand this.
Why can't you `//export` a Go function in package A - a function which
calls your cgo function?
And why can't you `//export` a Go function in package B - a function which
calls the exported Go function in package A ???
--
You received this message because you
Yes, but as noted, I can't do Go wrappers in this case.
On Mon, 1 Oct 2018 at 05:01, Tamás Gulácsi wrote:
> You could export the C function in a Go wrapper in package A, and use that.
> Maybe another exported Go wrapper is needed in package B, I don't know.
>
> --
> You received this message
You could export the C function in a Go wrapper in package A, and use that.
Maybe another exported Go wrapper is needed in package B, I don't know.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop
On Sun, 30 Sep 2018 at 17:55, Simon Ritchie wrote:
>
> Aagh! I misunderstood the question. Apologies for that.
>
I could have phrased the question more clearly also, sorry.
> There may still be a grain of usefulness in my answer. There are limits to
> the complexity of the C code that you
Aagh! I misunderstood the question. Apologies for that.
There may still be a grain of usefulness in my answer. There are limits to the
complexity of the C code that you can call with cgo. (It’s even worse if you
are calling C++, as I was.) You can magic away a lot of those problems by
Hi again,
As a followup, it seems the same or similar problems occur with assigning
function pointers across Go packages via cgo.
When trying to assign a C function "fC" defined via cgo in package A to a C
function pointer "fCPtr" in package B, even at runtime via Go, I get:
Undefined symbols
Hi all,
For info, short of a solution for linking cgo specific C functions cross
package, I think one can do this with C function pointers, which at least
is a close approximation of directly calls.
Best,
Scott
On Sunday, 30 September 2018 14:08:28 UTC+2, Scott Cotton wrote:
>
> Thanks
>
>
Thanks
In my case, believe it or not -- and for a very particular use case,
I cannot call the shared C functionality from Go, it must be called
from C. And I want to avoid telling consumers to use make to create a
C library, so that go get and modules will work.
It looks to me like your
Write a separate package to handle the C stuff and call it from the other two.
I built a wrapper for a c++ library:
https://github.com/goblimey/rplidar_sdk_go. The c++ code used various features
that defeated cgo, so I ended up with a multi-layered solution.
One thing I discovered is that
Howdy Gophers,
I've a got cgo question.
Suppose I want to use cgo in 2 packages and have one C function used in C
code in both packages.
Is there a way to do this with the go tool only? I am trying to avoid a
build that needs make or the like to build a c library,
or copying and renaming the
12 matches
Mail list logo
