Running on linux requires libssl 1.0, thus fails
billybraga opened this issue · 8 comments
Reproduction steps
- Use Ubuntu 20 or 22
- Install
LibGit2Sharp
in dotnet project - Run code that does
Repository.Clone(...)
Expected behavior
Repo is cloned
Actual behavior
An exception is thrown:
System.TypeInitializationException: The type initializer for 'LibGit2Sharp.Core.NativeMethods' threw an exception.
System.DllNotFoundException: Unable to load shared library 'git2-106a5f2' or one of its dependencies. In order to help diagnose loading problems, consider using a tool like strace. If you're using glibc, consider setting the LD_DEBUG environment variable:
/home/USER/dev/projects/PROJECT/src/PROJECT.Cli/bin/Release/net7.0/runtimes/linux-x64/native/git2-106a5f2.so: cannot open shared object file: No such file or directory
/home/USER/.dotnet/shared/Microsoft.NETCore.App/7.0.1/git2-106a5f2.so: cannot open shared object file: No such file or directory
/home/USER/dev/projects/PROJECT/src/PROJECT.Cli/bin/Release/net7.0/git2-106a5f2.so: cannot open shared object file: No such file or directory
libssl.so.1.0.0: cannot open shared object file: No such file or directory
/home/USER/.dotnet/shared/Microsoft.NETCore.App/7.0.1/libgit2-106a5f2.so: cannot open shared object file: No such file or directory
/home/USER/dev/projects/PROJECT/src/PROJECT.Cli/bin/Release/net7.0/libgit2-106a5f2.so: cannot open shared object file: No such file or directory
/home/USER/dev/projects/PROJECT/src/PROJECT.Cli/bin/Release/net7.0/runtimes/linux-x64/native/git2-106a5f2: cannot open shared object file: No such file or directory
/home/USER/.dotnet/shared/Microsoft.NETCore.App/7.0.1/git2-106a5f2: cannot open shared object file: No such file or directory
/home/USER/dev/projects/PROJECT/src/PROJECT.Cli/bin/Release/net7.0/git2-106a5f2: cannot open shared object file: No such file or directory
/home/USER/dev/projects/PROJECT/src/PROJECT.Cli/bin/Release/net7.0/runtimes/linux-x64/native/libgit2-106a5f2: cannot open shared object file: No such file or directory
/home/USER/.dotnet/shared/Microsoft.NETCore.App/7.0.1/libgit2-106a5f2: cannot open shared object file: No such file or directory
/home/USER/dev/projects/PROJECT/src/PROJECT.Cli/bin/Release/net7.0/libgit2-106a5f2: cannot open shared object file: No such file or directory
Using LD_DEBUG=files
, I get this (among other things):
10607: file=libssl.so.1.0.0 [0]; needed by /home/USER/dev/projects/PROJECT/src/PROJECT.Cli/bin/Release/net7.0/runtimes/linux-x64/native/libgit2-106a5f2.so
Version of LibGit2Sharp (release number or SHA1)
0.26.2
Operating system(s) tested; .NET runtime tested
- Ubuntu 20.04 (WSL), .NET 7.0.1
- Ubuntu 22.04 (azure devops), .NET 7.0.1
I guess something must have changed since #1747, since it seemed to work after it had bee fixed.
Seems like 0.27.0-preview-0182
solves this problem. Is it to be released soon?
@billybraga have you tried checking whether 0182 preview fixes it also for other distros (i.e fedora, arch)? It didn't work for me sadly.
@Miepee No, I have only tested on Ubuntu
Preview package fixed the issue on RHEL 7.9 Linux.
I had the same error on Ubuntu 22.04. After upgrading to the newest preview (0.27.0-preview-0182) the dependency isn't there anymore, but it seems that the problem remains and shows up at runtime:
LibGit2Sharp.LibGit2SharpException: could not load ssl libraries
at LibGit2Sharp.Core.Ensure.HandleError(Int32 result) in /_/LibGit2Sharp/Core/Ensure.cs:line 154
at LibGit2Sharp.Core.Ensure.ZeroResult(Int32 result) in /_/LibGit2Sharp/Core/Ensure.cs:line 172
at LibGit2Sharp.Core.Proxy.git_remote_fetch(RemoteHandle remote, IEnumerable`1 refSpecs, GitFetchOptions fetchOptions, String logMessage) in /_/LibGit2Sharp/Core/Proxy.cs:line 2289
at LibGit2Sharp.Commands.Fetch(Repository repository, String remote, IEnumerable`1 refspecs, FetchOptions options, String logMessage) in /_/LibGit2Sharp/Commands/Fetch.cs:line 80
at ...
Any ideas?
So seems like there's something else that influences it too then, if the issue both happens and doesn't happen on ubuntu 22.04 with the same preview package.
@mirkomaty if you set LD_DEBUG=files
, do you also see the same as in the first comment?
This should be fixed in the latest releases.