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 for architecture x86_64:
"_fC", referenced from:
__cgohack_fC in _cgo_main.o
(maybe you meant: _fCPtr, __cgohack_fC , __cgohack_fCPtr )
when building B. A builds just fine. It seems I just can't reference one
cgo C function across packages, which means I either need to make a C
library separately or copy+rename or use static functions fC tand have go
get and go modules work.
hmm...
maybe I'll copy the C code and make the functions static file members. If
that's the best solution, it is disappointing :(
Scott
On Sunday, 30 September 2018 14:20:41 UTC+2, Scott Cotton wrote:
>
> 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
>>
>> 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 solution, at least from the README calls
>> make, and I can't find an example (though I may well have missed
>> something) of shared package specific cgo C code outside of a C
>> library being called by C in another package.
>>
>> Can you clarify if or how your suggestion will meet my requirements (1
>> -- go tool only, no make, 2 -- cgo C function called by C in more than
>> one package)?
>>
>> Scott
>> On Sun, 30 Sep 2018 at 13:57, Simon Ritchie <simonritchie...@gmail.com>
>> wrote:
>> >
>> > 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 cgo has a nasty habit of rewriting the
>> Go code that calls C code, including trampling on your comments, so keeping
>> that code in a separate layer is a good idea.
>> >
>> > --
>> > You received this message because you are subscribed to a topic in the
>> Google Groups "golang-nuts" group.
>> > To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/golang-nuts/ruLltGrPWBg/unsubscribe.
>> > To unsubscribe from this group and all its topics, send an email to
>> golang-nuts+unsubscr...@googlegroups.com.
>> > For more options, visit https://groups.google.com/d/optout.
>>
>>
>>
>> --
>> Scott Cotton
>> http://www.iri-labs.com
>>
>
--
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
