Arch linux support #143
Comments
|
Copying the relevant stack trace: What's interesting is that it appears to be looking for |
Good question. The first thing I think we should do here is update NB.GV to the latest version of the libgit2sharp that has my portable changes in it, since that team made some changes to the native binaries package that might be relevant here. But yes, I may have some issues with path calculations as well that I need to look at. Or of course, consider it up for grabs if you're interested. |
|
You know, scratch that. I know that NB.GV works on linux because libgit2sharp does that now. So I'll look more closely at the failure to see what's going on. |
|
@onovotny what is "Arch Linux"? Is that a special distro that .NET Core or libgit2sharp doesn't support? |
|
No idea, was just going by the commenter in the thread. I assume it's this: https://www.archlinux.org/ That said, the real issue is probably that the Seems to be supported if you use the .NET Core 2 SDK https://wiki.archlinux.org/index.php/.NET_Core |
|
NB.GV loads from MSBuildCore when |
|
I don't see Arch Linux on the list of distros that .NET Core supports. As NB.GV builds with |
|
Okay, so, inserting myself into the conversation:
However, in the Meaning it doesn't work. Installing This is also revealed, in less detail, by libcurl SONAME issues are old and stupid, and not specific to NB.GV |
|
Seems I'm right - Curl on Arch is built against OpenSSL 1.1, and shares the same broken |
|
Okay, the problem is one you inherited from LibGit2Sharp.NativeBinaries As it happens, they already took the solution I was going to propose here: Switch libcurl variant away from OpenSSL. As of version 1.0.192, LibGit2Sharp.NativeBinaries builds libgit2 against GNUTLS instead of OpenSSL - this has a much more stable ABI, and removes the problem, fixing everything on distributions with OpenSSL 1.1 - Arch, Ubuntu 18.04, etc. So there's the fix: either switch to upstream LibGit2Sharp 0.24.1, or if you want to keep using your self-build, adjust your dependency to target LibGit2Sharp.NativeBinaries >= 1.0.192 (correcting the dllmap to point to the changed native lib names as appropriate) |
|
(This is an issue for building MSbuild on the previously mentioned distributions) |
|
libgit2sharp 0.24.1 doesn't include .NET Core support, which is why I was consuming my fork. By the time they shipped it, they removed my downlevel support for .NET Standard 1.x that I had added and only target .NET Standard 2.0. It turns out that it's a little difficult to consume that in NB.GV. :( I started working on it, but I don't know when I'll succeed. |
I'll give the latter of these two options a try. |
|
The repro steps I'm using are: docker run -it microsoft/aspnetcore-build /bin/bash
cd
mkdir try1
cd try1
dotnet new classlib
dotnet add package nerdbank.gitversioning
dotnet build |
|
I'm working in the fix143 branch, and updated to the latest official package from libgit2sharp. Still getting native binary load failures on the docker container running the |
|
@directhex do you have any idea of how to debug the problem? The docker image I'm using doesn't have |
|
Do you know which distribution the aspnetcore docker container is based on?
…Sent from my iPhone
On 30 Jun 2018, at 14:00, Andrew Arnott ***@***.***> wrote:
@directhex do you have any idea of how to debug the problem? The docker image I'm using doesn't have readelf, but it does have ldd:
ldd /root/.nuget/packages/nerdbank.gitversioning/2.1.65-g594b64598f/build/MSBuildFull/lib/linux/x86_64/libgit2-6311e88.so
linux-vdso.so.1 (0x00007fff11d8f000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f4deab2d000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f4dea910000)
libcurl-gnutls.so.4 => /usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4 (0x00007f4dea691000)
libssl.so.1.0.0 => not found
libcrypto.so.1.0.0 => not found
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f4dea477000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f4dea0d8000)
/lib64/ld-linux-x86-64.so.2 (0x00007f4deb044000)
libnghttp2.so.14 => /usr/lib/x86_64-linux-gnu/libnghttp2.so.14 (0x00007f4de9eb2000)
libidn2.so.0 => /usr/lib/x86_64-linux-gnu/libidn2.so.0 (0x00007f4de9c90000)
librtmp.so.1 => /usr/lib/x86_64-linux-gnu/librtmp.so.1 (0x00007f4de9a73000)
libssh2.so.1 => /usr/lib/x86_64-linux-gnu/libssh2.so.1 (0x00007f4de9847000)
libpsl.so.5 => /usr/lib/x86_64-linux-gnu/libpsl.so.5 (0x00007f4de9639000)
libnettle.so.6 => /usr/lib/x86_64-linux-gnu/libnettle.so.6 (0x00007f4de9402000)
libgnutls.so.30 => /usr/lib/x86_64-linux-gnu/libgnutls.so.30 (0x00007f4de9069000)
libgssapi_krb5.so.2 => /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2 (0x00007f4de8e1e000)
libkrb5.so.3 => /usr/lib/x86_64-linux-gnu/libkrb5.so.3 (0x00007f4de8b44000)
libk5crypto.so.3 => /usr/lib/x86_64-linux-gnu/libk5crypto.so.3 (0x00007f4de8911000)
libcom_err.so.2 => /lib/x86_64-linux-gnu/libcom_err.so.2 (0x00007f4de870d000)
liblber-2.4.so.2 => /usr/lib/x86_64-linux-gnu/liblber-2.4.so.2 (0x00007f4de84fe000)
libldap_r-2.4.so.2 => /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2 (0x00007f4de82ad000)
libunistring.so.0 => /usr/lib/x86_64-linux-gnu/libunistring.so.0 (0x00007f4de7f96000)
libhogweed.so.4 => /usr/lib/x86_64-linux-gnu/libhogweed.so.4 (0x00007f4de7d61000)
libgmp.so.10 => /usr/lib/x86_64-linux-gnu/libgmp.so.10 (0x00007f4de7ade000)
libgcrypt.so.20 => /lib/x86_64-linux-gnu/libgcrypt.so.20 (0x00007f4de77ce000)
libp11-kit.so.0 => /usr/lib/x86_64-linux-gnu/libp11-kit.so.0 (0x00007f4de7569000)
libidn.so.11 => /lib/x86_64-linux-gnu/libidn.so.11 (0x00007f4de7335000)
libtasn1.so.6 => /usr/lib/x86_64-linux-gnu/libtasn1.so.6 (0x00007f4de7122000)
libkrb5support.so.0 => /usr/lib/x86_64-linux-gnu/libkrb5support.so.0 (0x00007f4de6f16000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f4de6d12000)
libkeyutils.so.1 => /lib/x86_64-linux-gnu/libkeyutils.so.1 (0x00007f4de6b0e000)
libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007f4de68f7000)
libsasl2.so.2 => /usr/lib/x86_64-linux-gnu/libsasl2.so.2 (0x00007f4de66dc000)
libgpg-error.so.0 => /lib/x86_64-linux-gnu/libgpg-error.so.0 (0x00007f4de64c8000)
libffi.so.6 => /usr/lib/x86_64-linux-gnu/libffi.so.6 (0x00007f4de62bf000)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
@directhex It based on |
|
Stretch doesn't have libssl.so.1.0.0 for moronic reasons. But libgit native binaries $latest should be built against libgnutls, not libssl...?
…Sent from my iPhone
On 30 Jun 2018, at 14:34, Elijah ***@***.***> wrote:
@directhex It based on debian:stretch image.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
Not sure. What does this output of
|
|
I get the same issue when using |
|
I've got a build that works on Ubuntu 18 (and hopefully all the others listed here). It has issues on Windows that I'll work through over the next day or two, but I hope to have a fix published to nuget.org by the end of the week. |
Bumps [Microsoft.NET.Test.Sdk](https://github.com/microsoft/vstest) from 17.0.0 to 17.1.0. - [Release notes](https://github.com/microsoft/vstest/releases) - [Commits](microsoft/vstest@v17.0.0...v17.1.0) --- updated-dependencies: - dependency-name: Microsoft.NET.Test.Sdk dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Apparently the LibGit2Sharp doesn't support Arch Linux. I had a user complain about that here:
bcgit/bc-csharp#81 (comment)
The text was updated successfully, but these errors were encountered: