Is it possible to bundle other executables, C libraries, SQLite databases, etc with a Golang binary?

<p>One of the things that appeals to me about Go is the ability to ship a single self-reliant binary, sparing my users a lot of hassle and avoiding a lot of minor problems.</p> <p>Right now I&#39;m writing a tool that relies on ffmpeg (which is written in C and assembly) to analyse media files and extract frames or samples from them. Right now, it just expects the ffmpeg executable to be on the user&#39;s path, and calls out to it, capturing stdout/stderr.</p> <p>What I&#39;m curious about is whether I could bundle ffmpeg with it in some way -- either by attaching the executable to my Golang program itself, or by calling out to the C/asm code. I&#39;m also curious as to whether I could do something similar by attaching a SQLite database to the executable, or maybe some HTML templates for it to serve up, and things like that.</p> <p>Can anyone give me some tips about what&#39;s possible and impossible, and things I could read to learn more? I&#39;d appreciate it.</p> <hr/>**评论：**<br/><br/>graham_king: <pre><p>You can definitely bundle non-executable data, such as images and html templates. We use <a href="https://github.com/jteeuwen/go-bindata">https://github.com/jteeuwen/go-bindata</a> .</p> <p>Including <em>executable</em> binaries is really interesting, I haven&#39;t heard it done before. Let us know what you find.</p></pre>skyyr: <pre><p>A long time ago I rolled an executable and it&#39;s config file using go-bindata successfully. It after a bit like a self extracting archive and I guess that could work for seeding an sqlite file. </p> <p>go-bindata is awesome for that though</p></pre>: <pre><p>[deleted]</p></pre>jrkkrj1: <pre><p>This is a good answer. I&#39;ve done this to run standalone go on embedded devices.</p> <p>Example: <a href="https://www.osso.nl/blog/golang-statically-linked/" rel="nofollow">https://www.osso.nl/blog/golang-statically-linked/</a></p></pre>JackACooper: <pre><p>If you use the C api instead of wrapping the CLI, you could statically link libavcodec, etc...</p></pre>kodablah: <pre><p>I haven&#39;t looked into other OS&#39;s, but I highly suspect this is possible in Windows. I think the approach is to statically link it w/ linker flags. Then get the current process&#39;s hmodule and do a getprocaddress and work from there. I&#39;m sure other platforms will also let you statically link and resolve function pointers, I just haven&#39;t tried.</p></pre>ericzhill: <pre><p>Be careful with attaching executables to your binary because when they&#39;re unpacked on a target system you might trip the antivirus.</p></pre>sxan: <pre><p>I can&#39;t talk about bundling, but keep in mind that portable binaries aren&#39;t unique to Go. You can statically link most C binaries to nearly or the same extent as Go, assuming you have non shared versions of your dependencies on your compile system. They&#39;ll be just as portable as Go binaries, which are only portable between same GOOS, same GOARCH. There&#39;s nothing particularly magical about what Go does, except that it&#39;s the default, not the exception. And cross compiling is usually hella easier.</p></pre>detonator13: <pre><p>We solved this generically by modifying our build process to generate RPMs (CentOS) and push them into a local repo. The spec file can dictate where the unpacked files go (e.g. default config files, supplemental binaries, systemd service files,...). We haven&#39;t had a need to, but I suspect it would be trivial to include related binaries, assuming they&#39;re built on/for the same arch. From the time we tag a git commit, it&#39;s ~6 min end-to-end to being available as an update in the target server. (Half of this time is due to our build server polling frequency setting; the other half is waiting for the yum repo cron to index the new package.)</p></pre>Sythe2o0: <pre><p>Attaching the executable wouldn&#39;t work because it would be the executable for whatever system you were using when you attached it-- once you moved to a different platform it wouldn&#39;t run on said platform. (Granted, if that&#39;s not a concern of yours, or if you want to provide multiple binaries, this works, but be careful about licensing)</p> <p>Anything else I can think of either 1. requires that your user already has what you are calling out to installed (which you can provide instructions for how to install) or 2. requires a port of the utility in Go.</p> <p>You can call out to the C code through bindings like <a href="https://github.com/giorgisio/goav" rel="nofollow">https://github.com/giorgisio/goav</a>, but that still requires the user has ffmpeg installed, for example. Edit: I&#39;m thinking again and I might be entirely wrong on this, you might want to give this a shot and not include the extra binary at all</p></pre>