I'm using .net core on Linux specifically Manjaro 20.2.1, I'm learning .net core, I want to use EF commands, but it's slightly different how its works on Linux, I had installed the dotnet-ef tool whit this command:
dotnet tool install --global dotnet-ef --version 5.0.3
So when I try to run donet ef throws me this error:
/home/$USERNAME/.dotnet/tools/dotnet-ef: /snap/core18/current/lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.33' not found (required by /usr/lib/libstdc++.so.6)
But it seems that the GLIBC version that it's installed on my distro is: 2.33-3, and its seems that the version that it's looking for it's specifically the 2.33.
How I can get rid of this problem?
It seems that something in dotnet depends on GLIBC 2.33 but dotnet is tied to core18 which is using GLIBC 2.27.
λ snap list
Name Version Rev Tracking Publisher Notes
core 16-2.48.2.1 10823 latest/stable canonical✓ core
core18 20210128 1988 latest/stable canonical✓ base
dotnet-sdk 5.0.103 112 latest/stable dotnetcore✓ classic
λ file /snap/core18/current/lib/x86_64-linux-gnu/libc.so.6
/snap/core18/current/lib/x86_64-linux-gnu/libc.so.6: symbolic link to libc-2.27.so
Related
I just started getting this error today on my Linux system, building a net6 solution on Rider - It builds but won't run. I've tried upgrading my version of Microsoft.Data.SqlClient from nuget but that's made no difference. This was working fine last week.
There are a couple of things I've done that may have broken it - I got mono working over the weekend to try and get some legacy NETFramework code building for another project, for one. The other was a global update of ef tools dotnet tool update --global dotnet-ef as I had the 5.x tools version installed.
My OS has multiple runtimes installed...
dotnet --list-runtimes
Microsoft.AspNetCore.App 6.0.0 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 6.0.13 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 7.0.2 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.NETCore.App 6.0.0 [/usr/share/dotnet/shared/Microsoft.NETCore.App]
Microsoft.NETCore.App 6.0.13 [/usr/share/dotnet/shared/Microsoft.NETCore.App]
Microsoft.NETCore.App 7.0.2 [/usr/share/dotnet/shared/Microsoft.NETCore.App]
The app builds to target 6.0.
I'm a bit lost as to where to start trying to find problems - I#ve read about the netstandard2.0 version of this library being a kind of breaking stub, but the Assembly Explorer in Rider tells me that the version of Microsoft.Data.SqlClient in my bin directory is net6. I'm not sure what I should be seeing in the runtimes directory in here - I have a unix runtime shown there but NOT a linux specific runtime - Is this a red herring or am I on to something?
I've reverted the dotnet-ef tool by uninstalling it and running dotnet tool install --global dotnet-ef --version 5.0.0 - This hasn't helped at all.
TLDR: I think this is a bug in the .NET builds of Manjaro Linux. When you downloaded Microsoft's builds of .NET, it didn't have this bug and worked correctly.
This is what the OS says about itself:
# cat /etc/os-release
NAME="Manjaro Linux"
PRETTY_NAME="Manjaro Linux"
ID=manjaro
ID_LIKE=arch
BUILD_ID=rolling
ANSI_COLOR="32;1;24;144;200"
HOME_URL="https://manjaro.org/"
DOCUMENTATION_URL="https://wiki.manjaro.org/"
SUPPORT_URL="https://forum.manjaro.org/"
BUG_REPORT_URL="https://docs.manjaro.org/reporting-bugs/"
PRIVACY_POLICY_URL="https://manjaro.org/privacy-policy/"
LOGO=manjarolinux
And this is what .NET thinks about your OS:
sh-5.1# dotnet --info
.NET SDK (reflecting any global.json):
Version: 6.0.113
Commit: 4a23b50f97
Runtime Environment:
OS Name: manjaro
OS Version:
OS Platform: Linux
RID: arch-x64
Base Path: /usr/share/dotnet/sdk/6.0.113/
...
Do you see how confused .NET is about whether this is Arch Linux or Manjaro?
.NET has a fallback graph that tells it which assets from another OS it can use:
# jq '.runtimes' /usr/share/dotnet/shared/Microsoft.NETCore.App/6.0.13/Microsoft.NETCore.App.deps.json
{
"arch-x64": [
"arch",
"linux-x64",
"linux",
"unix-x64",
"unix",
"any",
"base"
]
}
But that only contains arch-x64 (that is, Arch Linux), not manjaro-x64.
If you try and build/run your application with the environment variable COREHOST_TRACE, you can see output like this:
HostRID is manjaro-x64
Falling back to base HostRID: linux-x64
So it finally decides this OS is Manjaro, but then has no idea that Manjaro is compatible with everything listed in the fallback graph above. It just falls back to Linux.
Unfortunately, Microsoft.Data.SqlClient is built for either Windows (windows) or for Unix (unix). .NET can't find a linux variant. It finally uses the fallback version of Microsoft.Data.SqlClient.dll, one that just prints errors instead of doing anything useful.
It seems that the issue was, in part, related to having 2 6.x framework versions installed, or with 6.0.13 - I'd tried installing the 6.x packages from the Manjaro repositories over the weekend to replace the script installs.
Dani's comment above pointed me in the right direction (https://github.com/dotnet/SqlClient/issues/1643#issuecomment-1265104713) - There's something odd going on here.
I removed them all and installed again using the .dotnet-install.sh script - that just did nothing, so I copied the 6.0.0 install from a backup folder (mv .old FTW) and it all fell into place again.
Whether this is an issue with 6.0.13 or with having multiples I'm not sure.
I'm trying to develop .NET Core in openSuse. I did install the SDK and everything in tutorials. Now, when I try to run dotnet new console command, I get this error:
No usable version of the libssl was found
Aborted (core dumped)
I found this answer: (.NET Core 2.1 SDK Linux x64 No usable version of the libssl was found), but didn't get what should I do to solve problem. They seems are deep-linuxer (which I'm not, I'm just trying to learn linux). Have any idea how to run the command?
UPDATE: System info:
openSUSE Leap 15.0
Kernel Version 4.12.14-lp150.12.22-default
OS Type:64-bit
I was having the same problem running sqlpackage on Ubuntu 20.04 while dotnet was working regularly.
dotnet is distributed through apt as well as sqlserver, but for some reasons sqlpackage is instead distributed via zip here (https://learn.microsoft.com/en-us/sql/tools/sqlpackage-download?view=sql-server-ver15) and is still affected by missing libssl1.0.
Solved with
wget http://security.ubuntu.com/ubuntu/pool/main/o/openssl1.0/libssl1.0.0_1.0.2n-1ubuntu5.6_amd64.deb
sudo dpkg -i libssl1.0.0_1.0.2n-1ubuntu5.6_amd64.deb
Can you install the libopenssl1_0_0 packages? .NET Core should pick it up and use it.
A slightly longer explanation for anyone who is curious:
OpenSSL is one of the most common cryptographic libraries used on Linux. It has multiple versions. Version 1.0 is kind of old, but heavily used. 1.1 is the newer version that was (relatively) recently released. 1.0 and 1.1 are not compatible. An application that expects 1.0 can not build against 1.1, nor run against it.
.NET Core 2.1, and all earlier versions only support OpenSSL 1.0.
Many Linux distributions are starting to make OpenSSL 1.1 the new default. But most of them still have a package for 1.0. So you just need to find and install that. On Fedora it's compat-openssl10. For openSuSE, it's libopenssl1_0_0. Then .NET Core will find it, pick it up and use it automatically.
Edit: As of March 2019, this shouldn't be required. We have updated .NET Core 2.1 and later to pick up and work with either OpenSSL 1.1 or 1.0 (whatever is available). So this problem should no longer happen with recent releases of .NET Core.
Ubuntu 22.04
wget http://security.ubuntu.com/ubuntu/pool/main/o/openssl1.0/libssl1.0.0_1.0.2n-1ubuntu5_amd64.deb
sudo dpkg -i libssl1.0.0_1.0.2n-1ubuntu5_amd64.deb
Still get this on Fedora 30 (with compat-openssl10 installed) when using the sqlpackage tool (https://learn.microsoft.com/en-us/sql/tools/sqlpackage-download?view=sql-server-2017).
$ dotnet --info
.NET Core SDK (reflecting any global.json):
Version: 2.2.203
Commit: e5bab63eca
Runtime Environment:
OS Name: fedora
OS Version: 30
OS Platform: Linux
RID: linux-x64
Base Path: /usr/share/dotnet/sdk/2.2.203/
Host (useful for support):
Version: 2.2.4
Commit: f95848e524
.NET Core SDKs installed:
2.2.203 [/usr/share/dotnet/sdk]
.NET Core runtimes installed:
Microsoft.AspNetCore.All 2.2.4 [/usr/share/dotnet/shared/Microsoft.AspNetCore.All]
Microsoft.AspNetCore.App 2.2.4 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.NETCore.App 2.2.4 [/usr/share/dotnet/shared/Microsoft.NETCore.App]
To install additional .NET Core runtimes or SDKs:
https://aka.ms/dotnet-download
Dotnet works fine on it's own. But running sqlpackage does not work:
$ sqlpackage /tsn:localhost /tu:xx /tp:yyy /A:Import /tdn:mydb /sf:mydb.bacpac
Importing to database 'mydb' on server 'localhost'.
No usable version of the libssl was found
Aborted (core dumped)
I looking up "No usable version of the libssl was found" in github. You'll find many variants of the .Net core security library in C, each varient has very specific dll loads for exact libssl libraries and everything has to match perfect despite it being named differently in many.
For raspberry pi / debian it wants libssl 1.0.2 exactly, nothing else.
sudo apt-get install libssl1.0.2
should do the trick for the pi! I can't speak to other variants.
I have installed the latest version of the .net core using pacman on an Arch Linux:
sudo pacman -S dotnet-sdk
Running dotnet --info shows the correct version:
Host (useful for support):
Version: 2.1.0
Commit: caa7b7e2ba
.NET Core SDKs installed:
2.1.0 [/opt/dotnet/sdk]
2.1.300 [/opt/dotnet/sdk]
I can run console applications, but when I run dotnet run in an ASP.NET Core directory return this error:
It was not possible to find any compatible framework version The
specified framework 'Microsoft.AspNetCore.App', version '2.1.0' was
not found.
Why though versions seem to match, it doesn't run?
More details:
ls /opt/dotnet/sdk/ returns:
2.1.300 NuGetFallbackFolder
Contents of the .csproj file:
<Project Sdk="Microsoft.NET.Sdk.Web">
<PropertyGroup>
<TargetFramework>netcoreapp2.1</TargetFramework>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Microsoft.AspNetCore.App" />
</ItemGroup>
</Project>
This question is old, but in case someone's trying to get .NET 5 to run on Arch, this can give you another solution.
If you build, publish and run the project specifying the platform runtime, dotnet will build a self-contained application, with all necessary platform specific dependencies.
You can do that with the --runtime/-r flag.
Examples for Arch:
dotnet build -r linux-x64
dotnet run -r linux-x64
dotnet publish -r linux-x64
Refer to Microsoft docs for the available runtime identifiers:
https://learn.microsoft.com/en-us/dotnet/core/rid-catalog
Edit:
I've also had less problems with paths using the AUR package instead of Snap's:
https://aur.archlinux.org/packages/dotnet-sdk-bin/
Edit 2:
After installing AUR's aspnet-runtime-bin package, all errors about Microsoft.AspNetCore.App not being found disappeared, without using the --runtime flag:
https://aur.archlinux.org/packages/aspnet-runtime-bin
.NET Core is not currently supported on Arch, so there's no guarantees that it will work at all. Currently the following distros are supported on 64-bit:
Red Hat Enterprise Linux 7, 6
CentOS 7
Oracle Linux 7
Fedora 27
Debian 9, 8.7 or later versions
Ubuntu 18.04, 17.10, 16.04, 14.04
Linux Mint 18, 17
openSUSE 42.3 or later versions
SUSE Enterprise Linux (SLES) 12 Service Pack 2 or later
Alpine Linux 3.7 or later versions
See this page for more info.
You can see these issues related to Arch in the dotnet repos:
https://github.com/dotnet/coreclr/issues/4409
https://github.com/dotnet/corefx/issues/19447
https://github.com/dotnet/core-setup/issues/3845
I don't have a proper solution for your problem but maybe a workaround. I am using elementary os and .net core 2.1 works just fine, but I noticed that my path to the metapackages is different from yours:
.NET Core SDK (reflecting any global.json):
Version: 2.1.300
Commit: adab45bf0c
Runtime Environment:
OS Name: elementary
OS Version: 0.4.1
OS Platform: Linux
RID: linux-x64
Base Path: /usr/share/dotnet/sdk/2.1.300/
Host (useful for support):
Version: 2.1.0
Commit: caa7b7e2ba
.NET Core SDKs installed:
2.0.0 [/usr/share/dotnet/sdk]
2.1.300 [/usr/share/dotnet/sdk]
You could try to copy the metapackages from your installation folder /opt/dotnet/shared to /usr/share/dotnet/shared
This guy over here has a similar problem using Fedora: https://github.com/dotnet/core-setup/issues/4022
#tura08 answer is wrong, because .NET Core should work on Arch Linux like on every other Linux system.
I was experiencing same issue so I just reported it https://github.com/dotnet/core-setup/issues/4216 and it seems dotnet-sdk package is missing aspnetcore-runtime-2.1 dependency. I wrote email to maintainer, so I hope he will fix package soon.
I had a similar issue trying to get global tools installed. Creating a symlink worked for me:
ln -s /opt/dotnet/ /usr/share/dotnet
Upgrading all the packages solved the problem:
pacman -Syu
It includes the dotnet-sdk package 2.1.300-2 updated on 2018-06-12 11:24 UTC:
https://www.archlinux.org/packages/community/any/dotnet-sdk/
I'm working with Node.js 8.9.4, the current LTS version.
If I download the 64 bit Linux binary distribution of that version from the Node.js website (https://nodejs.org/dist/v8.9.4/node-v8.9.4-linux-x64.tar.xz), then the node executable it includes will run on Red Hat Enterprise Linux 6. (I need to be able to target this version of RHEL).
I have also built Node v8.9.4 from source, following the instructions at https://github.com/nodejs/node/blob/master/BUILDING.md#building-nodejs-on-supported-platforms. Doing this required gcc 4.9.4 or newer, as per that page, because C++11 support is now required.
However, the node binary that results from that build will not run on RHEL 6, because the standard C++ library (libstdc++.so) that ships with RHEL 6 is from GCC 4.4.7. It's necessary to reference the libgcc and libstdc++ from the newer version of GCC that was used to build node to get it to work.
I think this means that the Linux binary distributions on the Node.js website are not built using the process described in the build instructions - if they were, they would not run on RHEL 6.
Is there any information on how the binary distributions of Node.js are built? Are there some options to the configure script that I'm missing?
(The reason for this question: I'm trying to build a Node C++ add-on, which needs to target RHEL 6, and hitting the same problem with the version of gcc required to build it vs. the version of the GCC/C++ runtime on RHEL 6. Yes, I could distribute the runtime libraries with my application, but there is obviously a better solution, because the binary distribution of Node is using it).
I need to build SpiderMonkey so that I can use it with emscripten. I succeeded in building version 1.8 (using the hack from here: http://pmelson.blogspot.fr/2007/12/building-didier-stevens-spidermonkey-in.html). But unfortunately version 1.8 lacks JSON support and apparently that came into existance with version 1.8.1.
Unfortunately I don't see any 1.8.1 tag/branch in CVS and I cannot use version 1.8.5 because the above hack no longer works with that version.
Any ideas for getting this to work in Cygwin?
You can use the following guide for building Spidermonkey in Cygwin.
SpiderMonkey Build Documentation
Windows build prerequisites
I have used the instructions to build the 1.8.5 version and it worked fine.