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.
