Embedded libusb? about gousb

[karalabe]

Initial attempt https://github.com/karalabe/gousb . I did rewrite the import paths to allow easier development, testing, use for myself. If you chose to accept the changes upstream, obviously I'll change them back.

It is covered by CI on linux, macos and windows. It seems to build correctly on android. On ios there's some strange error with a missing header file from the IOKit framework, I need to check whether it's my borked OS or whether it's a genuine issue.

[zagrodzki]

I'm not sure about this approach - I understand it assumes linking libusb statically into the output binary.

On one hand I understand the motivation between having a hermetic deployment that is buildable and deployable without any dependencies.

On the other hand, typical non-container deployment would explicitly rely on shared libraries to pick up bugfixes and improvements in all installed apps without the need to recompile. I believe this is the more common scenario.

Admittedly, I don't know much about how vendoring of non-Go libraries works here, so perhaps I'm missing something? Is there a way to use the included libusb in a dynamic fashion and only if there's no system-wide libusb?

[karalabe]

I agree that this is a rather philosophical question, but to highlight the main problem with relying on pre-existing dependencies, just look at the README's Windows section: https://github.com/kylelemons/gousb#installation-on-windows

On Linux and arguably OSX, dependency management is more or less clean, and if something's missing, it's easy to install. However there might be other platforms Windows, Android, iOS, etc where it may be hard to impossible to install dependencies.

My particular use case is a crypto currency hardware wallet. There I cannot really expect average Joe to know, care or even want to install libusb, or heavens forbid compile it himself.

Go's major advantage from my perspective over other languages are that the binaries are portable between machines. I can have a messy development machine and/or build server that assembles everything, but after that it's a single binary that can be moved around. That is imho a huge asset that should not be taken away from people lightly.

Of course I do understand the other perspective, that dynamic linking can get you bugfixes, however this still depends on the factors that the new version is compatible with the old one, or that the library is still available on your newer OS distribution years later (e.g. Ubuntu dropped the JSONCPP (or something) library, and it's also unavailable on other distros, meaning that any code relying on that breaks, and there's no easy way to fix it). A hermetic binary is much better from this perspective that you have much harder guarantees that it works and works the same way as always (which could mean the same buggy way).

If you don't feel confident enough about such a change, we could also perhaps ask for some input from main contributors to Go itself. I myself am surely not the best person to make such a decision, just trying to describe why it would be more that useful for the use cases I'm concerned with. Perhaps @davecheney @rakyll @bradfitz could share their thoughts in a sentence or two?

[zagrodzki]

To be clear: I don't think anyone is taking away the option to compile statically. One of the benefits of using pkgconfig is that in your build environment you can configure pkgconfig to provide flags for linking whatever libraries statically.

Another way is to pass the extra "-static" flag to linker ldflags, like this:

go build -ldflags="-extldflags=-static" ...

That will produce a binary with no runtime dependencies on libusb. I've confirmed that now on a Windows VM, just to be sure.

Overall I believe we're looking at two different scenarios:

• developer. If you're building packages, you're a developer. Managing dependencies and picking options for how you want to build your projects is expected. Setting up libusb for building gousb is part of the job.

• user or deployment. You want something that works and "building" is not a thing. It doesn't matter whether you're preparing a package for a server, an android app, desktop app, whatever. You expect the developer to deal with the complicated details and in the end you want something that is common for your platform.
  For Linux that might mean a package for your distro, or a static binary to use. For windows that means typically either a standalone binary, or .dll packaged together with the binary. Perhaps wrapped in an installer.
  "How" is really irrelevant to the user here and is only interesting to the developer that needs to prepare the deployment.
  This is the case I think of when you say "average Joe".

I don't think the dependencies setup in gousb, which itself is a library, is affecting your users. It might be affecting your developer setup, but not as much as I think you're saying it does.

[karalabe]

Requiring custom build flags will make any package using gousb non go gettable any more though.

[zagrodzki]

In your approach you move the platform features configuration from libusb configure into static CFLAGS parts of usb.go. That's what aclocal/autoconf/automake/configure in libusb is for and you're setting yourself up for build problems on platforms that you haven't tested on.

Embedding libusb while requiring the entire autoconf dance in integrated libusb makes the package no longer go-gettable, which defeats the point as I understand it.

I don't see any better solutions. Dependence on non-Go libraries in go is not going to fit entirely under the "go get" umbrella and I think that's acceptable.

I think I understand your arguments, and I disagree that it would be a good decision for gousb in general.

[karalabe]

I don't agree, but alas that's what forks are for :)