Libgit2sharp on centos

[JakeGinnivan]

CentOS Linux release 7.2.1511 (Core) 
NAME="CentOS Linux"
VERSION="7 (Core)"
ID="centos"
ID_LIKE="rhel fedora"
VERSION_ID="7"
PRETTY_NAME="CentOS Linux 7 (Core)"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:centos:centos:7"
HOME_URL="https://www.centos.org/"
BUG_REPORT_URL="https://bugs.centos.org/"

CENTOS_MANTISBT_PROJECT="CentOS-7"
CENTOS_MANTISBT_PROJECT_VERSION="7"
REDHAT_SUPPORT_PRODUCT="centos"
REDHAT_SUPPORT_PRODUCT_VERSION="7"

CentOS Linux release 7.2.1511 (Core) 
CentOS Linux release 7.2.1511 (Core) 

I am having trouble figuring out the packages I need to install for libgit2sharp on centos.

Mono: DllImport attempting to load: 'lib/linux/x86_64/libgit2-baa87df.so'.
Mono: DllImport error loading library '/var/lib/jenkins/workspace/-ci_feature_UploadArtifacts-7QPX2EFTVM4R6PXO6IQJQ5TJTOG6JD5T2C367DIKQAIC4J4YDYEQ/tools/gitversion/lib/linux/x86_64/libgit2-baa87df.so': 'libssl.so.1.0.0: cannot open shared object file: No such file or directory'.
Mono: DllImport error loading library '/var/lib/jenkins/workspace/-ci_feature_UploadArtifacts-7QPX2EFTVM4R6PXO6IQJQ5TJTOG6JD5T2C367DIKQAIC4J4YDYEQ/tools/gitversion/lib/linux/x86_64/libgit2-baa87df.so': 'libssl.so.1.0.0: cannot open shared object file: No such file or directory'.
Mono: DllImport error loading library '/usr/lib/lib/linux/x86_64/libgit2-baa87df.so': '/usr/lib/lib/linux/x86_64/libgit2-baa87df.so: cannot open shared object file: No such file or directory'.
Mono: DllImport error loading library '/usr/lib/lib/linux/x86_64/libgit2-baa87df.so': '/usr/lib/lib/linux/x86_64/libgit2-baa87df.so: cannot open shared object file: No such file or directory'.
Mono: DllImport error loading library 'lib/linux/x86_64/libgit2-baa87df.so': 'lib/linux/x86_64/libgit2-baa87df.so: cannot open shared object file: No such file or directory'.
Mono: DllImport error loading library 'lib/linux/x86_64/libgit2-baa87df.so': 'lib/linux/x86_64/libgit2-baa87df.so: cannot open shared object file: No such file or directory'.
Mono: DllImport error loading library 'lib/linux/x86_64/libgit2-baa87df.so': 'lib/linux/x86_64/libgit2-baa87df.so: cannot open shared object file: No such file or directory'.
Mono: DllImport unable to load library 'lib/linux/x86_64/libgit2-baa87df.so: cannot open shared object file: No such file or directory'.
Mono: AOT: FOUND method System.Runtime.ConstrainedExecution.CriticalFinalizerObject:Finalize () [0x7fe598288890 - 0x7fe5982888be 0x7fe59873515e]

Any help would be appreciated.

[bording]

The version of the libgit2.so file that is included in the NativeBinaries package is built on the Travis CI servers, which run Ubuntu.

Unfortunately, the version of OpenSSL that CentOS distributes is built with a non-standard soname, which is why libssl.so.1.0.0 isn't being found.

The quickest way to get that working would to be to clone the NativeBinaries repo and run the build script on CentOS. That would give you a version of the .so file that would work on CentOS.

[JakeGinnivan]

In the interest of keeping things lined up and official, would you be open to expanding your build process to use something like https://github.com/packpack/packpack to create a libgit2sharp.nativebinaries.centOS and a libgit2sharp.centOS package?

// @cavaliercoder

[bording]

@JakeGinnivan PackPack looks interesting, but for the NativeBinaries package, it actually does more than we need! We don't need RPM/Debian packages. We need the actual libgit2.so that is built on CentOS so that it could be bundled some way into the NuGet package.

More generally, the idea of using docker on Travis CI to build the CentOS binary does seem like a good way to actually get the artifact built, regardless of how it ends up being packaged/released.

If there was a way to build a CentOS-specific NativeBinaries package without also needing a new LibGit2Sharp package, I'd be more inclined to go that route to solve the issue. It just seems kind of crazy to need a distro-specific package like that.

With the current structure of the NativeBinaries package, if we started building a CentOS binary, we'd just add a centos.7-x64/native folder under the runtimes folder and put the binary there.

Then, once LibGit2Sharp works properly in .NET Core (#1318), everything would just work correctly.

With that in place, we'd be able to work on Desktop .NET Framework and .NET Core without issues.

The one remaining problem in this case would be Mono, because it doesn't have a way to alter what native binary it would try to load based on runtime identifiers. We're currently relying on Mono's DllMap support (the LibGit2Sharp.dll.config file) to choose between linux and osx. Unfortunately, it doesn't support anything more granular like individual distros: http://www.mono-project.com/docs/advanced/pinvoke/dllmap/#usage 😢

Assuming cross-platform support is available via .NET Core, I wonder how important it is to still worry about Mono?

---

There are a couple of ways I can think of to work around the Mono problem, but neither are really that desirable:

First, we could build the libgit2 binary against a private copy of OpenSSL instead of relying on the system-installed one, and theoretically that would result in a binary that would work on both Ubuntu and CentOS, and likely others as well. However, that would result in a rather large maintenance burden given how often important security updates are released for OpenSSL.

The other option would be to bypass the native library loading for both Mono and the .NET Framework altogether by directly calling dlopen/LoadLibrary in LibGit2Sharp instead of using DllImport attributes. That would give direct control on what paths are used to load libraries, so assuming there was some way to determine which distro was being used, the correct native binary could be loaded. This has major downsides though, because it's a non-trivial change, and I think that would also mean you'd be giving up the automatic support .NET Core has for handling all of this.

---

This whole situation is incredibly frustrating because it's this close to working properly for all scenarios, but there's no real good way forward right now.

[JakeGinnivan]

We are just using Mono because that is how we could take GitVersion cross plat. If we could get it working via .net core I think that would be fine. Is annoying for sure. Appreciate the response.