LIbGit2Sharp.Portable broken on (some?) linux distros

[NikkyAI]

TEMPORARY FIX: replace the file ~/.nuget/packages/libgit2sharp.nativebinaries/1.0.165/runtimes/linux-x64/native/libgit2-1196807.so with the libgit2.so file installed on your system

edit: the binaries supplied by libgit2sharp.nativebinaries are complied on ubuntu and will most likely only work on ubuntu derivates libgit2/libgit2sharp.nativebinaries#48

options are to wait or to try compiling libgit2 on archlinux and replace the binary in the aur package

on linux (tested on at least arch and centos) it does not find the .so file correctly when trying to do any git operations

email from the dev ( @aarnott )

Sorry to hear that. I suggest you take this up with the CoreCLR folks. The libgit2sharp library just depends on the libgit2sharp.native package, which uses the package format that CoreCLR is supposed to know how to load from. Apparently it doesn't work on Centos 7, which is a bit surprising. As a possible workaround, you could derive your own class from AssemblyLoadContext where you can override the native library load method and help it find the right one.

Nothing more I can do for you though. Sorry.

[NikkyAI]

might need more testing on the officially supported distros https://www.microsoft.com/net/core#linuxcentos

• RHEL 7
• Ubuntu 14.04
• Ubuntu 16.10
• Linux Mint 17
• Debian 8
• Fedora
• openSUSE

[skyem123]

So... as a workaround we could find the .so file ourselves and load it manually? Sounds a bit risky.

[NikkyAI]

if you can figure out how to load it ? and the so file is in platform/linux/

[skyem123]

If you know where the .so file is, it makes it easier... https://docs.microsoft.com/en-us/dotnet/api/system.runtime.loader.assemblyloadcontext?view=netcore-1.1.0 seems to be what he was referring to...

There's the LoadUnmanagedDll (DLL is the windows version of SO)... but... all the documentation seems to be "To be added."

That's not very helpful...

[NikkyAI]

you can test this behaviour with this repo https://github.com/NikkyAI/lg2s

git clone git@github.com:NikkyAI/lg2s.git
cd lg2s
./test.sh

if you want to try something out of a different branch there, ask so i can add contributors whoever solves it first and cleanest gets hugs

[skyem123]

Problem is I don't have a working Linux system to test. However, looking around a bit I have found this: https://github.com/libgit2/libgit2sharp.nativebinaries#specifying-custom-dll-names

[skyem123]

Reading a bit, it seems to be that we need to compile our own native libgit2sharp, then own libgit2sharp? I hope I'm misunderstanding there... Or we have to use some kind of reflection style hacks to replace the AssemblyLoadContext...

Either way, this seems very tricky.

[skyem123]

Some thinking... Libraries are only for 64-bit Linux distros? Something to be aware of for testing on virtual machines. What happens if we rename .so to .dll?

[AArnott]

Tip: AssemblyLoadContext is how I got it to work for my scenario where I couldn't rely on the CoreCLR to automatically find it.

https://github.com/AArnott/Nerdbank.MSBuildExtension/blob/master/src/Nerdbank.MSBuildExtension/netstandard1.5/ContextIsolatedTask.cs#L113 https://github.com/AArnott/Nerdbank.GitVersioning/blob/master/src/NerdBank.GitVersioning/GitExtensions.cs#L349

[NikkyAI]

i attempted to load the library git2-1196807 using a custom AssemblyLoader but that failed ..

de to load a program with an incorrect format.

i probably misunderstood the hints.. and i did not figure out how LoadUnmanagedDll is called

[NikkyAI]

i am also pretty sure its not whats needed to make this https://github.com/AArnott/libgit2sharp/blob/portable/LibGit2Sharp/Core/NativeMethods.cs#L94 work it is native code after all

@AArnott could you explain how a Custom AssemblyLoader affects System.Runtime.InteropServices.DllImport ?

[NikkyAI]

my current suspiscion is that this is not used which explains why it loads on windows.. maybe ? LibGit2Sharp.dll.config

<configuration>
    <dllmap os="linux" cpu="x86-64" wordsize="64" dll="git2-1196807" target="lib/linux/x86_64/libgit2-1196807.so" />
    <dllmap os="osx" cpu="x86,x86-64" dll="git2-1196807" target="lib/osx/libgit2-1196807.dylib" />
</configuration>

on windows it works fine even after deleting the file (running dotnet bin/Debug/netcoreapp1.1/lg2s.dll to prevent rebuilding the file )

[NikkyAI]

tested using travis trusty ( https://docs.travis-ci.com/user/trusty-ci-environment/ ) ssame environment as the LibGit2Sharp travis setup uses basically ubuntu in a container

and it does not break

[NikkyAI]

waiting on dotnet/coreclr#11005

[NikkyAI]

https://github.com/dotnet/coreclr/issues/10520#issuecomment-289692357 this can be a fix on the aur PKGBUILD we just need to copy the .so file into the default location if it really ignores the dll mapping

[AArnott]

could you explain how a Custom AssemblyLoader affects System.Runtime.InteropServices.DllImport ?

DllImport just takes a filename. The CLR at runtime has to find a path for that file, or let the OS find it via its probing path. The way CoreCLR lets you customize this native binary discovery is through AssemblyLoadContext, which your managed assembly must be running within in order to work.

[NikkyAI]

so if i understand this correctly i need o make a custom AssemblyLoader that can find the libgit.so and start the code that i want libgit to use also in there ? is there no way to register it and hook it into the current context ? also what is up with that xm file that provides the dllmapping ?

[AArnott]

so if i understand this correctly i need o make a custom AssemblyLoader that can find the libgit.so and start the code that i want libgit to use also in there ? is there no way to register it and hook it into the current context ?

Correct. You can get at the current AssemblyLoadContext and it exposes an event to help the CLR find managed assemblies. But it does not allow for helping to discover native libraries. For that, you must create your own type, override the virtual method, and then get your code running within it.

also what is up with that xm file that provides the dllmapping ?

I don't know. I think I heard that that's used by mono, but I didn't write that file and have never seen it used myself.

[NikkyAI]

generated by the last version of the test script, a few trace logs of lg2s trying to find git2-1196807 http://nikky.moe/alpacka/ if anybody else who has more time would want to diff them and see what the big difference is..

[NikkyAI]

this is now fixed.. more or less by replacing the .so file, keeping the issue broken as long as there is no real clean solution