The makefile includes a command to checkout unavailable branch

[hashrocketeer]

cd /home/dev/hashrocket/go/src/github.com/libgit2/git2go && git checkout origin/make-static && git submodule update --init && make install

The branch origin/make-static in git2go repo no longer exists!!!

• chris + jake

[derekparker]

So it looks like they merged and deleted that branch a while ago. It seems that the maintainers are saying that master tracks the latest stable release of libgit2. Problem is, the OS package managers are usually ~1 version behind. For example, the latest libgit2 is 0.24.0 and on my machine running Fedora 23, I get 0.23.4. Also, by default go build will not produce a statically compiled binary, so we can't distribute that binary the way it currently is through homebrew. For instance, on my machine:

➜  go-pear git:(master) ldd go-pear
    linux-vdso.so.1 (0x00007ffc81d8b000)
    libgit2.so.23 => /lib64/libgit2.so.23 (0x00007f1c80172000)
    libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f1c7ff55000)
    libc.so.6 => /lib64/libc.so.6 (0x00007f1c7fb93000)
    libcurl.so.4 => /lib64/libcurl.so.4 (0x00007f1c7f919000)
    libhttp_parser.so.2 => /lib64/libhttp_parser.so.2 (0x00007f1c7f713000)
    libz.so.1 => /lib64/libz.so.1 (0x00007f1c7f4fc000)
    libssl.so.10 => /lib64/libssl.so.10 (0x00007f1c7f282000)
    libcrypto.so.10 => /lib64/libcrypto.so.10 (0x00007f1c7ee24000)
    libssh2.so.1 => /lib64/libssh2.so.1 (0x00007f1c7ebf7000)
    librt.so.1 => /lib64/librt.so.1 (0x00007f1c7e9ef000)
    /lib64/ld-linux-x86-64.so.2 (0x0000555aeb960000)
    libnghttp2.so.14 => /lib64/libnghttp2.so.14 (0x00007f1c7e7cd000)
    libidn.so.11 => /lib64/libidn.so.11 (0x00007f1c7e598000)
    libssl3.so => /lib64/libssl3.so (0x00007f1c7e34e000)
    libsmime3.so => /lib64/libsmime3.so (0x00007f1c7e127000)
    libnss3.so => /lib64/libnss3.so (0x00007f1c7ddfd000)
    libnssutil3.so => /lib64/libnssutil3.so (0x00007f1c7dbd0000)
    libplds4.so => /lib64/libplds4.so (0x00007f1c7d9cc000)
    libplc4.so => /lib64/libplc4.so (0x00007f1c7d7c6000)
    libnspr4.so => /lib64/libnspr4.so (0x00007f1c7d587000)
    libdl.so.2 => /lib64/libdl.so.2 (0x00007f1c7d383000)
    libgssapi_krb5.so.2 => /lib64/libgssapi_krb5.so.2 (0x00007f1c7d134000)
    libkrb5.so.3 => /lib64/libkrb5.so.3 (0x00007f1c7ce4d000)
    libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x00007f1c7cc1b000)
    libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00007f1c7ca16000)
    liblber-2.4.so.2 => /lib64/liblber-2.4.so.2 (0x00007f1c7c807000)
    libldap-2.4.so.2 => /lib64/libldap-2.4.so.2 (0x00007f1c7c5b5000)
    libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f1c7c232000)
    libm.so.6 => /lib64/libm.so.6 (0x00007f1c7bf30000)
    libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f1c7bd19000)
    libkrb5support.so.0 => /lib64/libkrb5support.so.0 (0x00007f1c7bb09000)
    libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00007f1c7b905000)
    libresolv.so.2 => /lib64/libresolv.so.2 (0x00007f1c7b6e9000)
    libsasl2.so.3 => /lib64/libsasl2.so.3 (0x00007f1c7b4cc000)
    libselinux.so.1 => /lib64/libselinux.so.1 (0x00007f1c7b2a8000)
    libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007f1c7b072000)
    libpcre.so.1 => /lib64/libpcre.so.1 (0x00007f1c7ae02000)
    libfreebl3.so => /lib64/libfreebl3.so (0x00007f1c7ab81000)

That means we would have to require users to have installed libgit2 themselves so we can dynamically link against it, and then do all kinds of nonsense to make sure versions line up since git2go only vendors the version of libgit2 it uses in the next branch. But that is terrible.

The 2 potential solutions I see are:

1. Just use the next branch and continue to compile the vendored libgit2 so that go-pear can statically link against it.
2. Try to cross-compile within a container that has everything it needs to produce a truly static binary (e.g. ldd go-pear returns "not a dynamic executable").

I'm leaning more towards 1, since they vendor libgit2 on that branch, it should be safe to build against that, especially for what go-pear is using it for. Anyways, I'll poke around at this some more tonight.

[derekparker]

As a workaround you could install the latest version of libgit2-devel via your package manager, and then checkout the branch in git2go that corresponds to that version (e.g. v23) and then within the go-pear directory you can run go install to produce a dynamically linked executable that will work fine locally, since you'll have everything needed to dynamically link.

[hashrocketeer]

Thanks Derek! We ended up copying the executable from a different computer but wanted to let you know about it.