After recent twitter discussions about usable software, I thought that one thing I could do to relieve a common problem of users of my software would be to build static binaries. I know this would be helpful because I never get any questions/bugs about installs with vcfanno or indexcov for which I provide static binaries (thanks to use of #golang) even though they are (I think) widely used.
Since most of my tools are command-line apps, that rely on htslib this can be difficult. I ended up using a docker image based on alpine linux and building an htslib without libcurl. Alpine linux uses musl so we can avoid the warnings/errors seen when trying to use a binary built with a new version of (g)libc on a system with an older (g)libc.
The docker image is musl-hts-nim and, using that, I made a static binary so that, given a nim file, for example this one where I recently helped Ming (note in that issue, Ming had problems with libhts.so which would have been avoided with a static binary), we can create a static binary with:
$ hts_nim_static_builder -s ./atac.nim --deps "hts@>=0.2.7" --deps "binaryheap"
#This will create a static binary in atac:
$ ldd ./atac
statically linked
$ file ./atac
./atac: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, not stripped
#hts_nim_static_builder is avaiable here
See the README section for more information and advanced usage.
I hope that this will make using hts-nim even more enticing for building command-line tools that utilize htslib.