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/c31db183-c69a-43e4-bee3-8f113d5e37c4n%40googlegroups.com.
