I'm missing a native binary

[tyalie]

The script says, that it's missing a native git binary and the FAQ redirected me here.

I'm on an Ubuntu 20.04 with Powershell 7 if that helps.

[refactorsaurusrex]

Hey @Gansgar... thanks for reporting this. I'll look at it today.

[tyalie]

Wow. That's a response time.

But hey that's great ^^

[refactorsaurusrex]

Wow. That's a response time.

I happened to be sitting at my computer when this came in. 😄

So it looks like Ubuntu 20.04 isn't officially supported by PowerShell. Did you install it using sudo snap install powershell --classic? That's what I did to repro the problem on my vm, although it still seems like it should be working. The native binary is actually there, so I'm not sure why it's failing. I'm going to add some additional logging and see what specific messages I get.

[refactorsaurusrex]

Here's the solution. Problem now is that the build currently dumps all native binaries in the same directory, and I need to retain the output of targeting both ubuntu.18.04-x64 and linux-x64. Both have the same name but (apparently) different contents.

For future reference, here is the error that was generated:

2020-05-25 14:48:33.447 -05:00 [ERR] Error encountered during Commit()
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 setting the LD_DEBUG environment variable: libgit2-106a5f2: cannot open shared object file: No such file or directory
   at LibGit2Sharp.Core.NativeMethods.git_libgit2_init()
   at LibGit2Sharp.Core.NativeMethods.InitializeNativeLibrary()
   at LibGit2Sharp.Core.NativeMethods..cctor()
   --- End of inner exception stack trace ---
   at LibGit2Sharp.Core.NativeMethods.git_repository_open_ext(git_repository*& repository, FilePath path, RepositoryOpenFlags flags, FilePath ceilingDirs)
   at LibGit2Sharp.Core.Proxy.git_repository_open_ext(String path, RepositoryOpenFlags flags, String ceilingDirs)
   at LibGit2Sharp.Repository.IsValid(String path)
   at JournalCli.Cmdlets.JournalCmdletBase.ValidateGitRepo()
   at JournalCli.Cmdlets.JournalCmdletBase.Commit(GitCommitType commitType)

[tyalie]

Thanks a lot for the solution. I'll try it again when I'm booting into Ubuntu. And yes, I installed it through snap. Should we close the issue with that?

[refactorsaurusrex]

Well, I still need to get the change built into journal-cli. :) It's a little hacky because dotnet doesn't seem to provide a precise way to distinguish between Ubuntu releases.

In the meantime, I can give you the correct binary and tell you where to put it, if you'd like. I'll upload it here when I get back to my personal machine.

[refactorsaurusrex]

Notes to self:

• It's Really Hard To Package Native Libraries for PowerShell Modules PowerShell/PowerShell#8861
• Add native dll resolver PowerShell/PowerShell#11032

[refactorsaurusrex]

@Gansgar If you drop this file in /home/{username}/.local/share/powershell/Modules/JournalCli/{version}, it should resolve your issue while I work on a proper fix. You'll know it's fixed if a .git directory appears in your journal's root directory after running a command such as New-JournalEntry.

[tyalie]

Wow thanks. That worked.

[refactorsaurusrex]

Not fixed. :(

[refactorsaurusrex]

I have a solution for this, just haven't had time to wrap it up. It will be done within a couple of weeks. I've been avoiding it because its been a real pain in the ass.

[lboening]

@refactorsaurusrex Unfortunately, I encountered the identical error on Debian 10.7. The approach you mentioned above in the May 25 solution--to copy the lib.git.so such and such file into the local journal folder--did not alone help. I then entered that folder and ran a "git init" command. An empty ".git" folder now exists. But, I still get the error.

[refactorsaurusrex]

Thanks for that info @lboening. I suspect this problem affects most Linux distros. I'm still fiddling with a solution that doesn't involve creating a massively bloated module packages.

[refactorsaurusrex]

I never did find a satisfying solution to distributing native binaries like this, so I'm going the complete opposite direction: I'm completely ripping out the git integration. Instead, I'm building end to end encrypted synchronization to S3 which will take advantage of S3's object versioning. The upside of doing this is you'll be able to access your journal from any internet-connected machine; the downside is that you have to opt in to cloud sync in order to enable versioning of your journal which, of course, entails some risk.