Can't you build (make go build for you) those libraries?
For example, see github.com/godror/godror just includes the sources of that
third party library in an "odpi" subdir, and with
```
/*
#cgo CFLAGS: -I./odpi/include -I./odpi/src -I./odpi/embed
#include "dpi.c"
*/
import "C"
```
it is compiled automatically.
Caveat: for "go get" to download a directory, it must include a sth.go file
("require.go" in the odpi/* subdirs).
But it may work that your precompiled libs in a subdir, with a mock .go
file gets downloaded.
But how will it found by your lib/app ?
Tamás
Jan a következőt írta (2023. október 12., csütörtök, 8:14:41 UTC+2):
> Thanks Richard. Indeed, as you pointed out the downside is the bloating of
> the git repo, but it makes sense.
>
> But does the user have to manually clone the repository and move the `.a`
> file to, let's say, /usr/local/lib, or does a simple `go get` magically
> does everything ?
>
>
> On Thursday, October 12, 2023 at 2:29:21 AM UTC+2 Richard Wilkes wrote:
>
>> It isn't a great solution, but I currently include the built library
>> files and necessary headers in the git repo alongside the Go code. You can
>> see an example here
>> https://github.com/richardwilkes/unison/tree/main/internal/skia where I
>> include the skia library I built for use in my UI framework, unison.
>>
>> The main downside of this is bloating the git repo with the binary .a and
>> .dll files... but I've not found a better way to handle it. glfw, which
>> unison also depends upon, does something very similar.
>>
>> - Rich
>>
>> On Wednesday, October 11, 2023 at 2:58:23 AM UTC-7 Jan wrote:
>>
>>> hi,
>>>
>>> I'm developing a couple of ML framework/libraries for Go that depend on
>>> C/C++ code. Once C-libraries dependencies are installed, the CGO
>>> integration work great.
>>>
>>> Now, for end-users that just want to use these Go libraries, having to
>>> figure out how to manually build and install those C/C++/Rust dependencies
>>> is a hassle -- sadly each one with a different type of build system.
>>>
>>> I offer pre-built `.tgz` files (for a limited set of architectures) with
>>> the required `.h` and `.a/.so` files along the releases, which facilitates.
>>> But it's still a hassle to install -- and no auto-uninstall if someone is
>>> no longer using the Go module.
>>>
>>> I was wondering if others have figured out how to handle this in a nicer
>>> way. Is there a recommended way to distribute prebuilt CGO dependencies ?
>>>
>>> I like how Python wheels (`.whl` files) solve the issue, by including
>>> the pre-built libraries in a sub-directory of the python library
>>> installation. I was hoping there would be a similar way (maybe with a
>>> separate tool) to integrate with `go.mod`.
>>>
>>> Any pointers, thoughts or suggestions are very appreciated.
>>>
>>> Thanks!
>>> Jan
>>>
>>> ps: While searching I saw similar questions, but none that exactly
>>> answered this aspect of distribution. Just in case, apologies if it's a
>>> duplicate question.
>>>
>>
--
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/1624fe5e-ec87-4022-91f5-d9990594c183n%40googlegroups.com.
