Compiling in libvirt requires libvirt on the machine or it won't work even if not used.

[purpleidea]

It seems if you try and run a binary that has this library compiled in on a machine that doesn't have libvirt, you get errors. How do we get around this limitation, in particular since it shouldn't cause any errors if we never run any libvirt code.

Thanks

[berrange]

There's no nice way around that AFAIK. The go binary dynamically links to libvirt.so, so there's no way to avoid the need to install it. CGo doesn't have any concept of using dlopen() as a layer of indirection to avoid a hard dependency AFAIK. The only alternative would be to provide a stub C library implementing the extract same ABI as libvirt.so, which is stubbed to always return errors. This is a non-trivial undertaking, to the extent that you might as well just install libvirt.so for real.

[purpleidea]

@berrange Would the new dlopen stuff in Golang1.8 help with this?

It turns out that this is turning out to be a bit of an issue for some :(

[purpleidea]

Eg: https://beta.golang.org/src/plugin/plugin_dlopen.go

[berrange]

Not really very practical to use, not least because we want to support multiple GO versions without forking the codebase for each one.

[berrange]

The other alternative approach is to structure your application differently. Instead of building everything into one monolithic binary, have a minimal main binary, and separate binaries to provide extensions, communicating between them with GRPC or similar. This is a fairly common pattern for large apps in Go. That way you can isolate libvirt bits in a extension binary and only install that binary when needed

[purpleidea]

Well if you think of any other ideas, please let me know! Having everything in a single blob is a major feature we'd like to keep.

[purpleidea]

I don't suppose there's anything useful in this article which can help with this issue?
https://blog.ksub.org/bytes/2017/02/12/exploring-shared-objects-in-go/
cheers!

[cdrage]

@purpleidea

There's also https://github.com/digitalocean/go-libvirt which is an alternative implementation which uses RPC instead of the C bindings.

[purpleidea]

On Fri, Feb 17, 2017 at 3:28 PM, Charlie Drage ***@***.***> wrote: @purpleidea There's also https://github.com/digitalocean/go-libvirt which is an alternative implementation which uses RPC instead of the C bindings.

Yeah, I know about that. I considered it, except @berrange and libvirt pros say that it's dangerous. So IDK. `hands-up-idk-emoji`

[berrange]

Libvirt won't support anyone using the RPC protocol directly. The only public API is that provided by libvirt.so. The fact that the QEMU driver functionality is then delegated to libvirtd is a private implementation detail we reserve the right to change arbitrarily. So sooner or later anyone using the RPC protocol directly instead of via libvirt.so will get broken

[berrange]

I'm closing this because I don't think it is really a bug, not is it something we can really fix given current CGo support. My recommendation is use a modular architecture for applications that need it to be optional, with separate "plugin" processes communicating with GRPC or similar rather than a monolithic binary containing everything.