LIbGit2Sharp.Portable broken on (some?) linux distros about alpacka HOT 20 OPEN

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

from alpacka.

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.

from alpacka.

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

from alpacka.

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

from alpacka.

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

from alpacka.

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...

from alpacka.

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

git clone [email protected]: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

from alpacka.

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

from alpacka.

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.

from alpacka.

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?

from alpacka.

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

from alpacka.

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 ?

from alpacka.

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 )

from alpacka.

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

from alpacka.

waiting on dotnet/coreclr#11005

from alpacka.

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

from alpacka.

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.

from alpacka.

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 ?

from alpacka.

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..

from alpacka.

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

from alpacka.