Created go opus bindings using cgo, but how to properly release?

[Hraban Luyat]

Hi guys,

Been working on libopus bindings for Go:

https://github.com/hraban/opus

But I'm struggling to find the right setup to release it. Somehow, it doesn't feel right to require everyone who uses a program depending on this package to have libopus installed. But dynamic linking is the only portable way I could find to release this. Anything else just leads to trouble with linking or headers.

Ideally, I'd like to offer people a chance to import "github.com/hraban/opus" and statically link their own pre-built libopus into their final binary. Or not, and let them decide if they want users of their binary to build libopus themselves. Libopus is not available in all package managers yet, and I'd be reluctant to depend on a lib that requires my users to build and install libopus themselves from source.

Do you have some examples of libraries wrapping relatively obscure libs? What are the options for releasing and what did you choose?

Sincerely

Hraban

[Daniël de Kok]

On Sun, Feb 22, 2015 at 11:05 AM, Hraban Luyat <hra...@0brg.net> wrote:
> Been working on libopus bindings for Go:
>
> https://github.com/hraban/opus
>
> But I'm struggling to find the right setup to release it. Somehow, it
> doesn't feel right to require everyone who uses a program depending on this
> package to have libopus installed.

[snip]

I am facing pretty much the same problem -- for three years now I have
maintained a binding to liblinear (golinear). There are two questions
that I commonly get:

- I cannot compile your package: turns out they didn't install liblinear.
- I have liblinear installed, but cannot compile your package. In this
case they often use Debian or Ubuntu which contain an ancient version
of liblinear and/or they use MacPorts which uses a non-standard
location.

I am now seriously considering embedding liblinear in the golinear
package, since it's just a small number of source files that don't
require any special build machinery. I think, this option may apply in
your case as well, since (assuming that your are talking about Xiph
Opus) it only consists of a small number of C headers/files.

Of course, the downside is that this approach increases compile time
compared to linking to a library.

Kind regards,
Daniël de Kok

[Dmitry Vyukov]

The race detector (go test -race) depends on an obscure native library.
To solve the dependency problem, I cat all C++ source files into a
single file, compile it to .o object file, rename it to .syso file and
put into package directory. Go command automatically picks up syso
files and links them, so it is completely invisible to race detector
users. To make it portable, I put a bunch of syso files named as
race_linux_amd64.syso, race_windows_amd64.syso, etc into the package
dir. It is not necessary to cat all source files together, you can
just put a bunch of syso files, but it just makes things a little bit
nicer.

[Hraban Luyat]

Wow! Neat trick. The wiki page about this has an unsettling warning:

> it shouldn't use too much stack (a safe value is less than ~100 bytes) or
> terrible things will happen.

https://code.google.com/p/go-wiki/wiki/GcToolchainTricks

But since it's an external lib, I have /no idea/ how much stack it can
use. Even if I profile it now, what tells me there's not some weird
edge case that will blow the stack up to 1KB?

What do you suggest: should I take the risk and favor easy deployment?
Bundle the .syso files and hope it never blows up the stack?

Or should I go for maximum safety at the cost of requiring every
developer importing the lib to copy the .a file into their build
directory?

Is there an expected way to do it, or can I just use my best
judgement? I'd go for Explicit Is Better Than Implicit, copy .a
yourself.

What do others think?

Cheers,

Hraban

PS: Yes this is xiph.org's libopus.

[Dmitry Vyukov]

That's true only if you call the native code directly. If you use cgo
to call it, then this restriction does not apply.