-
-
Notifications
You must be signed in to change notification settings - Fork 171
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Visual Studio Code/OmniSharp on Ubuntu 18.04: DllNotFoundException #417
Comments
I'm also running into this on a slightly older version of NBGV when using a VS Online environment (which is running the remote VS Code backend in a linux container). It's complicated further by the fact that Debian 9 doesn't include libssl 1.0.0 or libcrypto 1.0.0. Instead, it includes OpenSSL 1.0.2 and 1.1. $ lsb_release -sd
Debian GNU/Linux 9.11 (stretch) $ ldd /var/nuget/nerdbank.gitversioning/2.3.38/build/runtimes/linux-x64/native/libgit2-a904fc6.so
linux-vdso.so.1 (0x00007ffe19ed3000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007ff0a6fd3000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007ff0a6db6000)
libssl.so.1.0.0 => not found
libcrypto.so.1.0.0 => not found
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007ff0a6a17000)
/lib64/ld-linux-x86-64.so.2 (0x00007ff0a7505000) |
Yep, this basically breaks using VS Code for C# projects that use GitVersioning, because the project load failure means no Intellisense, no F12, etc. |
Strangely enough, it only affects Omnisharp. I don't have any issue doing builds from the command line. |
|
Omnisharp runs on Mono, not CoreCLR. That may be relevant. |
Tagging @ethomson as this appears to pertain to LibGit2 |
I don't understand how LibGit2Sharp loads libgit2 anymore. @bording might have some insight here? |
Which version of LibGit2Sharp is being used? |
That's |
Unfortunately, I'm not sure there's going to be a great answer here. Currently, the LibGit2Sharp native binaries package requires different native binaries for different linux platforms. When using .NET Core, there is a built-in mechanism to choose the correct binary using the platform RID. Mono doesn't have anything like that. What it supports is much more limited. The native binaries package includes a
That's why you see it trying to use the When running on Ubuntu 18.04, you would need to be using |
@AArnott Any chance of dumping libgit2sharp in favor of something else, like shelling out to the git CLI? |
Or maybe should we be poking Omnisharp to move to .NET Core instead of Mono? |
I'm afraid the git CLI can't substitute for what NB.GV is doing. We're looking at each commit in history individually, scanning the trees/blobs and making decisions at each point. So we'd have to spawn git.exe (or linux equivalent) half a dozen times per commit in history to replace what we use libgit2sharp for here. The perf of that would undoubtedly be abominable. NB.GV already shows up on build perf stats for large repos so I don't want to do anything to make it slower. But we do need to make it work. We're brainstorming options over in the conversation on this PR: libgit2/libgit2sharp#1618 |
So, I got nbgv to work inside OmniSharp on Ubuntu 19.10. The general idea is to have a MSBuild task which calls There were two gotchas:
@AArnott , is this an approach you're willing to consider? Creating a MSBuild task which pre-loads The task could look like this: using System;
using System.Runtime.InteropServices;
using System.Text;
using Microsoft.Build.Utilities;
namespace NerdBank.GitVersioning.Mono
{
public class LoadLibGit2Task : Task
{
private const string libdl = "libdl.so.2";
[DllImport(libdl)]
public static unsafe extern void* dlopen(byte* filename, int flags);
public static int RTLD_LAZY = 1;
public unsafe override bool Execute()
{
this.Log.LogMessage("Starting LoadLibGit2Task");
const string libName = "path/to/runtimes/ubuntu.18.04-x64/native/libgit2-572e4d8.so";
fixed (byte* filename = Encoding.UTF8.GetBytes(libName))
{
var libHandle = new IntPtr(dlopen(filename, RTLD_LAZY));
this.Log.LogMessage($"Loaded libgit2.so as {libHandle}");
}
return true;
}
}
} and be plugged into MSBuild like this: <UsingTask TaskName="NerdBank.GitVersioning.Mono.LoadLibGit2Task" AssemblyFile="path-to/nbgv-mono.dll" />
<Target Name="LoadLibgit2" BeforeTargets="GetBuildVersion">
<Message Text="Loading Libgit2" />
<NerdBank.GitVersioning.Mono.LoadLibGit2Task />
</Target> |
@qmfrederik In addition to the unpleasantness around needing to modify the binaries (soname patching) and needing to restrict this to mono-on-linux only, the other problem with your proposed approach is that it is hardcoded to the Ubuntu 18.04 binary. What about all the other distros that it could be run on? You would need to implement logic that understood the RID graph and all the binaries that ship in the package (which can change over time) to know which lib to try and load. |
I'd initially scope it to do its magic only on Ubuntu (and perhaps Debian) releases with OpenSSL 1.1. You could read the data from An alternative approach would be to just try & load all the different copies of It's very unpleasant for sure, but I don't see any other options at the moment. And I'd really like to have OmniSharp working in Visual Studio Code 😄 . |
@qmfrederik One other thing, are you sure that calling |
@bording Using
I had some issues in the past where I've created a prototype fix for this (for Ubuntu) at https://github.com/qmfrederik/nbgv-mono. It works for me by adding a package reference to nbgv-mono if you remove LibGit2Sharp.dll.config. Let's see if I can add Debian support, as I've noticed @jkeech seems to be on Debian 9. |
@jkeech @bradwilson If you're up to it, can you give this a try:
This works for me, let me know if that's the case for you guys, too. |
@bording FYI - I got a suggestion in the Mono Gitter channel to "build against gnutls not OpenSSL. The ABI is much much more cross-distro-friendly". Coming from someone who spends a lot of time packaging for different distros. |
I think something is wrong with either the dll.config file or the directory structure of the libgit2 binaries shipped with the nuget package. See below that the linux binary is in the
|
@AArnott It looks like the folder structure for the linux binary you're bundling needs to be updated. |
After altering the LibGit2Sharp.dll.config to point at the real path under the lib folder for the dllmap os="linux", my intellisense started working again in VS Code. EDIT: |
I just tried it and it worked for me though. And it's clearly a bug. I'm going to go ahead and make the change that @kglassmire suggests. |
Yeah I went back and looked again and see where I went wrong. I thought they were both Ubuntu 18.04 but one was actually 19.04. It is hard to tell because they are both the "Lubuntu" flavor of Ubuntu and they don't look that different to me in terms of desktop between 18.04 and 19.04 The one that wasn't working though was 19.04. I confirmed that your fix works with v3.1.74 and Ubuntu 18.04 as this issue is titled. Thank you for the fix! |
It works on Ubuntu 19.10, at least for me in a Docker container. I haven't tried 19.04. |
Yeah just to follow-up on your comment @AArnott -- It's not working on regular Ubuntu 19.10 for me inside VS Code (not Lubuntu). I have a VM of that sitting around, too and set the test up on there. It does not affect just building via dotnet cli if that is how you're testing -- this still works splendidly. Not sure if you're just invoking dotnet build or something in a Docker container. This is very Omnisharp specific it seems. I have seen some threads in the past regarding this underlying lib2gitsharp stuff and saw some mention of how RIDs are resolved for different Linux distributions (even varying by version) so maybe that's where this is happening. It's inside of VS Code when Omnisharp is initializing the C# plug-in when a C# project is opened in VS Code. The way I was testing this across all the OSes I was trying was:
All this being said, the fact that it works on Ubuntu 18.04 is probably good enough for most and I am appreciative you even got that working as I imagine supporting these different distros because of libssl is probably excessively time-consuming. I know you said that eventually these package bundles for libssl might not even be necessary after they finish some stuff on libssl's side so I am content with an 18.04 fix as I primarily use Ubuntu VMs to debug Docker containers. |
Thanks for that, @kglassmire. Yes, I see now that on an Ubuntu 19.10 that it fails. I'm not sure what I was looking at before.
So ya, it's typical ssl dependency problems. So as you say, it will hopefully be fixed when libgit2sharp offers a managed HTTPS layer. |
I think I'm seeing this with v3.1.74 still. Is this supposed to be working? Or is there a workaround? My case is running a solution in a VS Code Dev Containers, the standard C# (.NET Core 3.1) one, with no changes. This is how their stock Dockerfile looks like BTW: #-------------------------------------------------------------------------------------------------------------
# Copyright (c) Microsoft Corporation. All rights reserved.
# Licensed under the MIT License. See https://go.microsoft.com/fwlink/?linkid=2090316 for license information.
#-------------------------------------------------------------------------------------------------------------
FROM mcr.microsoft.com/dotnet/core/sdk:3.1
# This Dockerfile adds a non-root user with sudo access. Use the "remoteUser"
# property in devcontainer.json to use it. On Linux, the container user's GID/UIDs
# will be updated to match your local UID/GID (when using the dockerFile property).
# See https://aka.ms/vscode-remote/containers/non-root-user for details.
ARG USERNAME=vscode
ARG USER_UID=1000
ARG USER_GID=$USER_UID
# [Optional] Version of Node.js to install.
ARG INSTALL_NODE="true"
ARG NODE_VERSION="lts/*"
ENV NVM_DIR=/home/vscode/.nvm
# [Optional] Install the Azure CLI
ARG INSTALL_AZURE_CLI="false"
# Avoid warnings by switching to noninteractive
ENV DEBIAN_FRONTEND=noninteractive
# Configure apt and install packages
RUN apt-get update \
&& apt-get -y install --no-install-recommends apt-utils dialog 2>&1 \
#
# Verify git, process tools, lsb-release (common in install instructions for CLIs) installed
&& apt-get -y install git openssh-client less iproute2 procps apt-transport-https gnupg2 curl lsb-release \
#
# Create a non-root user to use if preferred - see https://aka.ms/vscode-remote/containers/non-root-user.
&& groupadd --gid $USER_GID $USERNAME \
&& useradd -s /bin/bash --uid $USER_UID --gid $USER_GID -m $USERNAME \
# [Optional] Add sudo support for the non-root user
&& apt-get install -y sudo \
&& echo $USERNAME ALL=\(root\) NOPASSWD:ALL > /etc/sudoers.d/$USERNAME\
&& chmod 0440 /etc/sudoers.d/$USERNAME \
#
# [Optional] Install Node.js for ASP.NET Core Web Applicationss
&& if [ "$INSTALL_NODE" = "true" ]; then \
#
# Install nvm and Node
mkdir ${NVM_DIR} \
&& curl -so- https://raw.githubusercontent.com/creationix/nvm/v0.34.0/install.sh | bash 2>&1 \
&& chown -R vscode:vscode ${NVM_DIR} \
&& /bin/bash -c "source $NVM_DIR/nvm.sh \
&& nvm install ${NODE_VERSION} \
&& nvm alias default ${NODE_VERSION}" 2>&1 \
&& INIT_STRING='[ -s "$NVM_DIR/nvm.sh" ] && \\. "$NVM_DIR/nvm.sh" && [ -s "$NVM_DIR/bash_completion" ] && \\. "$NVM_DIR/bash_completion"' \
&& echo $INIT_STRING >> /home/vscode/.bashrc \
&& echo $INIT_STRING >> /home/vscode/.zshrc \
&& echo $INIT_STRING >> /root/.zshrc \
#
# Install yarn
&& curl -sS https://dl.yarnpkg.com/$(lsb_release -is | tr '[:upper:]' '[:lower:]')/pubkey.gpg | apt-key add - 2>/dev/null \
&& echo "deb https://dl.yarnpkg.com/$(lsb_release -is | tr '[:upper:]' '[:lower:]')/ stable main" | tee /etc/apt/sources.list.d/yarn.list \
&& apt-get update \
&& apt-get -y install --no-install-recommends yarn; \
fi \
#
# [Optional] Install the Azure CLI
&& if [ "$INSTALL_AZURE_CLI" = "true" ]; then \
echo "deb [arch=amd64] https://packages.microsoft.com/repos/azure-cli/ $(lsb_release -cs) main" > /etc/apt/sources.list.d/azure-cli.list \
&& curl -sL https://packages.microsoft.com/keys/microsoft.asc | apt-key add - 2>/dev/null \
&& apt-get update \
&& apt-get install -y azure-cli; \
fi \
#
# Clean up
&& apt-get autoremove -y \
&& apt-get clean -y \
&& rm -rf /var/lib/apt/lists/*
# Switch back to dialog for any ad-hoc use of apt-get
ENV DEBIAN_FRONTEND=dialog The .NET Core image is using Debian 10, in case it makes a difference. |
@Meligy Please open a new issue. NB.GV's dependency on libgit2sharp, which transitively depends on libssl, means that each linux distribution needs attention to work. This issue is about Ubuntu while your issue is about Debian 10. |
Coming from google, on debian 10, the fix from #482 (comment) works wonders. |
I'm using ubuntu 20.04 and having same OmniSharp error. The command I'm run was: After replace the .so file, OmniSharp work's well. |
@reinaldocoelho Can you please try the latest 3.4 beta? It should totally fix this for you. |
In the time of problem I´m using the version 3.3.37. I will try that and return :-) |
Hi @AArnott, sorry for the long time to anwer. Thank you for the answer :-) |
Visual Studio Code/OmniSharp fails to properly load
.csproj
projects which contain a reference to NerdBank.GitVersioning. I've tried with the latest version of the 3.0 series of nbgv, both from NuGet and the CI feed.Don't have much time to deep dive into this at the moment. Here are a couple of things I've noticed:
dotnet build
works properly.lib/
part in the path (lib/linux-x64/libgit2-572e4d8.so
)linux-x64/libgit2-572e4d8.so
should load fine on my platform, see theldd
output below.Here's the full stack error:
Here's the ldd output:
Leaving this here in case anyone else sees a similar problem (or even better, knows how to fix it).
The text was updated successfully, but these errors were encountered: