Yep, I want a solution on how to distribute C-dependencies of libraries that use CGO, so end users don't have to manually sort out dependencies of various libraries.
Thanks for trying though. On Wednesday, October 11, 2023 at 1:10:12 PM UTC+2 Peter Galbavy wrote: > Hang on - I missed your original statement that you are building > *libraries* yourself. I am building executables. Sorry for the confusion > and my too-fast scan reading! > > On Wednesday, 11 October 2023 at 12:08:53 UTC+1 Peter Galbavy wrote: > >> If you link statically, e.g. from my Dockerfile: >> >> go build -tags netgo,osusergo --ldflags '-s -w -linkmode external >> -extldflags=-static' >> >> then the libraries are in the single binary. I also then use "upx" to >> compress the resulting binaries to save a little space. The build tags are >> there to not require GLIBC for user and dns lookups. >> >> >> >> On Wednesday, 11 October 2023 at 11:43:20 UTC+1 Jan wrote: >> >>> Edit: ...so folks using your library don't need to install them manually >>> ? What about uninstalling ? >>> On Wednesday, October 11, 2023 at 12:41:40 PM UTC+2 Jan wrote: >>> >>>> Thanks Peter, but I don't follow ... I also use docker to build the >>>> pre-built binaries. >>>> >>>> But how do you distribute them, so folks using your library don't think >>>> to install them ? >>>> >>>> On Wednesday, October 11, 2023 at 12:32:57 PM UTC+2 Peter Galbavy wrote: >>>> >>>>> I use a docker container (golang:bullseye seems the most compatible) >>>>> and build static binaries. This is feasible as long as your dependencies >>>>> do >>>>> not require dynamic loading of dependencies. >>>>> >>>>> Poor (my Dockerfile skills) example here: >>>>> https://github.com/ITRS-Group/cordial/blob/main/Dockerfile >>>>> >>>>> Peter >>>>> >>>>> On Wednesday, 11 October 2023 at 10:58:23 UTC+1 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/52054323-ac00-4b15-92f7-7c95cb84b1a1n%40googlegroups.com.
