search

dotnet / runtime

.NET is a cross-platform runtime for cloud, mobile, desktop, and IoT apps.
https://docs.microsoft.com/dotnet/core/
MIT License
15.37k stars 4.75k forks source link

Archlinux - Enable Support #5646

Closed davzucky closed 1 year ago

davzucky commented 8 years ago

Following on this problem that I raised with Archlinux #4408 I would still make progress to enable the support of the platform

Getting Archlinux support move forward

This is the first goal that I have. For that I could imagine the following step to get started,

  1. Building manually a dotnetcli package for archlinux and getting it deploy
  2. Updating coreclr and corefx build to recognize Archlinux and pick up this custom package
  3. Creating an Archlinux server to get daily build or Archlinux including dotnet cli
  4. Creating an official pacman (archlinux package manager) package

I have already 1 and 2 (for coreclr) running locally, however I don't know what is the process to enable this type of infrastructure step like 1.

ellismg commented 8 years ago

I'm interested to know if the native components built cleanly out of the box or there are changes that had to be made?

I responded to the other issue about some easy workaround you can use to help move things forward when trying to use init-tools.sh.

davzucky commented 8 years ago

@ellismg, The build of native component out of the box after installing the required dependency for archlinux which I summarize there However I haven't run the test at the moment because they required to be build on Windows at the moment from the instruction. I used the replaced the native library build on my machine to get dotnet cli running properly, so I would say it's working

abrodersen commented 8 years ago

@davzucky I have reached the same point as you. I built the native components from coreclr and corefx on Arch Linux and used them to replace the native libs in a downloaded copy of the Dotnet CLI. I am able to run dotnet --info successfully. However, more complicated commands like dotnet restore result in a segmentation fault. Have you made any progress?

janvorli commented 8 years ago

@abrodersen would you be able to run the command under gdb or lldb and copy here the call stack when the segfault happens? You would do: gdb --args /full/path/to/dotnet restore When it hits the SIGSEGV, you would use bt command in the gdb to dump the call stack. With lldb, you'd run lldb -- /full/path/to/dotnet restore When it hits the SIGSEGV, you would use bt command in the lldb to dump the call stack.

abrodersen commented 8 years ago

@janvorli I was able to get a bit further and I have useful information for you now. I build coreclr and corefx native components on Arch Linux. I used the v1.0.0 tags on both repositories. (I had to cherry pick dotnet/coreclr#5304) I downloaded the 1.0.0 release of the CLI for Fedora 23.

I copied the following libraries into the CLI:

Here is the result of restoring a dotnet new project after performing said procedures:

gdb --args $(realpath ../dotnet) restore
GNU gdb (GDB) 7.11.1
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /home/aaron/dev/dotnet/bootstrap/output/dotnet...(no debugging symbols found)...done.
(gdb) run
Starting program: /home/aaron/dev/dotnet/bootstrap/output/dotnet restore
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
[New Thread 0x7ffff46c6700 (LWP 24887)]
[New Thread 0x7ffff3ec5700 (LWP 24888)]
[New Thread 0x7ffff36c4700 (LWP 24894)]
[New Thread 0x7ffff2ec3700 (LWP 24896)]
[New Thread 0x7ffff26c2700 (LWP 24897)]
[New Thread 0x7ffff1b48700 (LWP 24898)]
[New Thread 0x7fffe2583700 (LWP 24899)]
[Thread 0x7fffe2583700 (LWP 24899) exited]
[New Thread 0x7fffe2583700 (LWP 24900)]
[New Thread 0x7fffe1660700 (LWP 24901)]
[New Thread 0x7fffe0e5f700 (LWP 24902)]
log  : Restoring packages for /home/aaron/dev/dotnet/bootstrap/output/test_proj/project.json...
log  : Installing System.Xml.XPath 4.0.1.
[New Thread 0x7fffe0246700 (LWP 24903)]
[New Thread 0x7fffdfa45700 (LWP 24904)]
[New Thread 0x7fffdf244700 (LWP 24905)]
[New Thread 0x7fffdea43700 (LWP 24906)]
log  : Installing System.Xml.XPath.XDocument 4.0.1.
log  : Installing System.Xml.XmlDocument 4.0.1.
log  : Installing System.Text.Encoding.CodePages 4.0.1.
[New Thread 0x7fff5fffd700 (LWP 24907)]
[New Thread 0x7fff5f7fc700 (LWP 24908)]
log  : Installing System.Diagnostics.StackTrace 4.0.1.
log  : Installing System.Diagnostics.FileVersionInfo 4.0.0.
log  : Installing Microsoft.CodeAnalysis.Analyzers 1.1.0.
log  : Installing System.Security.Cryptography.Csp 4.0.0.
log  : Installing System.Security.Cryptography.Cng 4.2.0.
log  : Installing runtime.native.System.Net.Http 4.0.1.
log  : Installing System.Security.Principal 4.0.1.
log  : Installing System.Security.Cryptography.OpenSsl 4.0.0.
log  : Installing System.Security.Claims 4.0.1.
log  : Installing runtime.native.System.Security.Cryptography 4.0.0.
log  : Installing runtime.native.System.Net.Security 4.0.1.
log  : Installing System.Security.Principal.Windows 4.0.0.
log  : Installing Libuv 1.9.0.
log  : Installing Microsoft.CodeAnalysis.CSharp 1.3.0.
log  : Installing Microsoft.CodeAnalysis.VisualBasic 1.3.0.
log  : Installing Microsoft.CSharp 4.0.1.
log  : Installing System.Reflection.Emit.Lightweight 4.0.1.
log  : Installing Microsoft.NETCore.DotNetHostPolicy 1.0.1.
log  : Installing Microsoft.NETCore.Runtime.CoreCLR 1.0.2.
log  : Installing Microsoft.VisualBasic 10.0.1.
log  : Installing NETStandard.Library 1.6.0.

Thread 17 "dotnet" received signal SIG34, Real-time event 34.
[Switching to Thread 0x7fff5f7fc700 (LWP 24908)]
0x00007ffff79c50af in pthread_cond_wait@@GLIBC_2.3.2 ()
   from /usr/lib/libpthread.so.0
(gdb) bt
#0  0x00007ffff79c50af in pthread_cond_wait@@GLIBC_2.3.2 ()
   from /usr/lib/libpthread.so.0
dotnet/coreclr#1  0x00007ffff635f9b2 in CorUnix::CPalSynchronizationManager::ThreadNativeWait(CorUnix::_ThreadNativeWaitData*, unsigned int, CorUnix::ThreadWakeupReason*, unsigned int*) ()
   from /home/aaron/dev/dotnet/bootstrap/output/shared/Microsoft.NETCore.App/1.0.0/libcoreclr.so
dotnet/coreclr#2  0x00007ffff635f5e3 in CorUnix::CPalSynchronizationManager::BlockThread(CorUnix::CPalThread*, unsigned int, bool, bool, CorUnix::ThreadWakeupReason*, unsigned int*) ()
   from /home/aaron/dev/dotnet/bootstrap/output/shared/Microsoft.NETCore.App/1.0.0/libcoreclr.so
dotnet/coreclr#3  0x00007ffff636452e in CorUnix::InternalWaitForMultipleObjectsEx(CorUnix::CPalThread*, unsigned int, void* const*, int, unsigned int, int) ()
   from /home/aaron/dev/dotnet/bootstrap/output/shared/Microsoft.NETCore.App/1.0.0/libcoreclr.so
dotnet/coreclr#4  0x00007ffff6364742 in WaitForSingleObjectEx ()
   from /home/aaron/dev/dotnet/bootstrap/output/shared/Microsoft.NETCore.App/1.0.0/libcoreclr.so
dotnet/coreclr#5  0x00007ffff60b6f32 in CLREventBase::WaitEx(unsigned int, WaitMode, PendingSync*) ()
   from /home/aaron/dev/dotnet/bootstrap/output/shared/Microsoft.NETCore.App/1.0.0/libcoreclr.so
---Type <return> to continue, or q <return> to quit---

Next I'll try compiling glibc with debug symbols to hopefully get more information.

janvorli commented 8 years ago

@abrodersen The signal 34 should not cause break in in the gdb. But I have seen similar thing happen during my testing of a problem that happens on Linux kernel 4.2.6. So I wonder if it could be the same - can you tell me what your Linux kernel version is?

abrodersen commented 8 years ago

I just so happen to be running that exact kernel. EDIT oops I guess it isn't the same

$ uname -a
Linux aaron-arch 4.6.2-1-ARCH dotnet/coreclr#1 SMP PREEMPT Wed Jun 8 08:40:59 CEST 2016 x86_64 GNU/Linux

Arch did just push out 4.6.3, should I update to that and try again?

janvorli commented 8 years ago

You can try that. I still have no clear idea what's wrong with that kernel version or what range of kernel versions have problems. I have created issue dotnet/coreclr#6016 to track it.

abrodersen commented 8 years ago

Ok so aparently it's just gdb being paranoid. I disabled gdb breaking on SIG34 and I reran the debug session. This time, it got to the actual segfault:

gdb --args $(realpath ../dotnet) restore
GNU gdb (GDB) 7.11.1
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /home/aaron/dev/dotnet/bootstrap/output/dotnet...(no debugging symbols found)...done.
(gdb) run
Starting program: /home/aaron/dev/dotnet/bootstrap/output/dotnet restore
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
[New Thread 0x7ffff46c6700 (LWP 3555)]
[New Thread 0x7ffff3ec5700 (LWP 3556)]
[New Thread 0x7ffff36c4700 (LWP 3557)]
[New Thread 0x7ffff2ec3700 (LWP 3558)]
[New Thread 0x7ffff26c2700 (LWP 3559)]
[New Thread 0x7ffff1b48700 (LWP 3560)]
[New Thread 0x7fffe2583700 (LWP 3564)]
[Thread 0x7fffe2583700 (LWP 3564) exited]
[New Thread 0x7fffe2583700 (LWP 3568)]
[New Thread 0x7fffe1660700 (LWP 3569)]
[New Thread 0x7fffe0e5f700 (LWP 3570)]
log  : Restoring packages for /home/aaron/dev/dotnet/bootstrap/output/test_proj/project.json...
[New Thread 0x7fffdebdd700 (LWP 3571)]
[New Thread 0x7fff5fffd700 (LWP 3572)]
[New Thread 0x7fff5f7fc700 (LWP 3573)]
[Thread 0x7fffe1660700 (LWP 3569) exited]
[Thread 0x7fff5f7fc700 (LWP 3573) exited]
[New Thread 0x7fff5f7fc700 (LWP 4165)]
[New Thread 0x7fffe1660700 (LWP 4166)]
[New Thread 0x7fff5effb700 (LWP 4170)]
[New Thread 0x7fff5e7fa700 (LWP 4171)]
[New Thread 0x7fff5dff9700 (LWP 4172)]
[New Thread 0x7fff5d7f8700 (LWP 4173)]
[New Thread 0x7fff5cff7700 (LWP 4174)]
[New Thread 0x7fff27fff700 (LWP 4567)]
[New Thread 0x7fff277fe700 (LWP 4568)]
[New Thread 0x7fff26ffd700 (LWP 4569)]

Thread 20 "dotnet" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fff5d7f8700 (LWP 4173)]
0x00007ffff7deb810 in __tls_get_addr () from /lib64/ld-linux-x86-64.so.2
(gdb) bt
#0  0x00007ffff7deb810 in __tls_get_addr () from /lib64/ld-linux-x86-64.so.2
dotnet/coreclr#1  0x00007ffff60134a4 in ThreadNative::PAL_GetCurrentThread() ()
   from /home/aaron/dev/dotnet/bootstrap/output/shared/Microsoft.NETCore.App/1.0.0/libcoreclr.so
dotnet/coreclr#2  0x00007fff7c8adc36 in ?? ()
dotnet/coreclr#3  0x00007fff5d7f7030 in ?? ()
dotnet/coreclr#4  0x0000000000000000 in ?? ()
janvorli commented 8 years ago

Given the Linux kernel version, I bet the segfault will be at a different place each time, most of the time at place where sigsegv cannot happen. To confirm it is the same issue as the one we are looking into, can you please try to prefix the dotnet command with COMPlus_INTERNAL_ThreadSuspendInjection=0 and see if it fixes the problem for you? So, e.g. COMPlus_INTERNAL_ThreadSuspendInjection=0 dotnet new

abrodersen commented 8 years ago

Setting that environment variable indeed fixed the problem. So it's an issue with newer Linux kernels then?

janvorli commented 8 years ago

Looks like that's the case.

abrodersen commented 8 years ago

Interesting. I'll try install Arch's LTS kernel and see what happens.

janvorli commented 8 years ago

Thanks a lot, that would be helpful.

ghost commented 8 years ago

As of this moment, Arch, Gentoo, Alpine and Void Linices can build CoreCLR+CoreFxNative. Would be nice to enable us to build the entire runtime from scratch to shoot and contribute with packaging system scripts; emerge, apkbuild, xbps etc. like we have for Debian alone atm: https://github.com/dotnet/core-setup/tree/master/packaging/deb.

abrodersen commented 8 years ago

I've put together an AUR package that I think works. Arch users, please help me test it: https://aur.archlinux.org/packages/dotnet-cli/

bigolewannabe commented 8 years ago

AUR package looks good to me. Console app and web app were successfully generated and ran. Haven't had much time to do more than that.

libratian commented 8 years ago

Many thanks, works like a charm as long as I dont' use VsCode. I dont know how this error is specifically related to this arch-build, since other people have it, too: https://github.com/Microsoft/vscode/issues/4244 Log:

Error while Installing .NET Core Debugger:
Starting 'dotnet --info'
.NET Command Line Tools (1.0.0-preview2-003121)

Product Information:
 Version:            1.0.0-preview2-003121
 Commit SHA-1 hash:  1e9d529bc5

Runtime Environment:
 OS Name:     arch
 OS Version:  
 OS Platform: Linux
 RID:         arch.-x64

Creating /home/patrick/.vscode/extensions/ms-vscode.csharp-1.2.0/coreclr-debug/project.json
Telemetry is: Enabled

log  : Restoring packages for /home/patrick/.vscode/extensions/ms-vscode.csharp-1.2.0/coreclr-debug/project.json...

error: System.IO 4.1.0 provides a compile-time reference assembly for System.IO on .NETCoreApp,Version=v1.0, but there is no run-time assembly compatible with arch.-x64.

error: System.Globalization.Calendars 4.0.1 provides a compile-time reference assembly for System.Globalization.Calendars on .NETCoreApp,Version=v1.0, but there is no run-time assembly compatible with arch.-x64.
error: System.Globalization 4.0.11 provides a compile-time reference assembly for System.Globalization on .NETCoreApp,Version=v1.0, but there is no run-time assembly compatible with arch.-x64.
error: System.Diagnostics.Tracing 4.1.0 provides a compile-time reference assembly for System.Diagnostics.Tracing on .NETCoreApp,Version=v1.0, but there is no run-time assembly compatible with arch.-x64.
error: System.Diagnostics.Tools 4.0.1 provides a compile-time reference assembly for System.Diagnostics.Tools on .NETCoreApp,Version=v1.0, but there is no run-time assembly compatible with arch.-x64.
error: System.Diagnostics.Debug 4.0.11 provides a compile-time reference assembly for System.Diagnostics.Debug on .NETCoreApp,Version=v1.0, but there is no run-time assembly compatible with arch.-x64.
error: System.Console 4.0.0 provides a compile-time reference assembly for System.Console on .NETCoreApp,Version=v1.0, but there is no run-time assembly compatible with arch.-x64.
error: System.Collections 4.0.11 provides a compile-time reference assembly for System.Collections on .NETCoreApp,Version=v1.0, but there is no run-time assembly compatible with arch.-x64.
error: System.Diagnostics.Process 4.1.0 provides a compile-time reference assembly for System.Diagnostics.Process on .NETCoreApp,Version=v1.0, but there is no run-time assembly compatible with arch.-x64.
error: System.Net.Http 4.1.0 provides a compile-time reference assembly for System.Net.Http on .NETCoreApp,Version=v1.0, but there is no run-time assembly compatible with arch.-x64.
error: System.Security.Cryptography.Algorithms 4.2.0 provides a compile-time reference assembly for System.Security.Cryptography.Algorithms on .NETCoreApp,Version=v1.0, but there is no run-time assembly compatible with arch.-x64.
error: System.IO.MemoryMappedFiles 4.0.0 provides a compile-time reference assembly for System.IO.MemoryMappedFiles on .NETCoreApp,Version=v1.0, but there is no run-time assembly compatible with arch.-x64.
error: Microsoft.Win32.Primitives 4.0.1 provides a compile-time reference assembly for Microsoft.Win32.Primitives on .NETCoreApp,Version=v1.0, but there is no run-time assembly compatible with arch.-x64.
error: System.IO.Compression 4.1.0 provides a compile-time reference assembly for System.IO.Compression on .NETCoreApp,Version=v1.0, but there is no run-time assembly compatible with arch.-x64.
error: System.IO.FileSystem 4.0.1 provides a compile-time reference assembly for System.IO.FileSystem on .NETCoreApp,Version=v1.0, but there is no run-time assembly compatible with arch.-x64.
error: System.Net.Primitives 4.0.11 provides a compile-time reference assembly for System.Net.Primitives on .NETCoreApp,Version=v1.0, but there is no run-time assembly compatible with arch.-x64.
error: System.Net.Sockets 4.1.0 provides a compile-time reference assembly for System.Net.Sockets on .NETCoreApp,Version=v1.0, but there is no run-time assembly compatible with arch.-x64.
error: System.Reflection 4.1.0 provides a compile-time reference assembly for System.Reflection on .NETCoreApp,Version=v1.0, but there is no run-time assembly compatible with arch.-x64.
error: System.Reflection.Extensions 4.0.1 provides a compile-time reference assembly for System.Reflection.Extensions on .NETCoreApp,Version=v1.0, but there is no run-time assembly compatible with arch.-x64.
error: System.Reflection.Primitives 4.0.1 provides a compile-time reference assembly for System.Reflection.Primitives on .NETCoreApp,Version=v1.0, but there is no run-time assembly compatible with arch.-x64.
error: System.Resources.ResourceManager 4.0.1 provides a compile-time reference assembly for System.Resources.ResourceManager on .NETCoreApp,Version=v1.0, but there is no run-time assembly compatible with arch.-x64.
error: System.Runtime 4.1.0 provides a compile-time reference assembly for System.Runtime on .NETCoreApp,Version=v1.0, but there is no run-time assembly compatible with arch.-x64.
error: System.Runtime.Extensions 4.1.0 provides a compile-time reference assembly for System.Runtime.Extensions on .NETCoreApp,Version=v1.0, but there is no run-time assembly compatible with arch.-x64.
error: System.Runtime.Handles 4.0.1 provides a compile-time reference assembly for System.Runtime.Handles on .NETCoreApp,Version=v1.0, but there is no run-time assembly compatible with arch.-x64.
error: System.Runtime.InteropServices 4.1.0 provides a compile-time reference assembly for System.Runtime.InteropServices on .NETCoreApp,Version=v1.0, but there is no run-time assembly compatible with arch.-x64.
error: System.Runtime.InteropServices.RuntimeInformation 4.0.0 provides a compile-time reference assembly for System.Runtime.InteropServices.RuntimeInformation on .NETCoreApp,Version=v1.0, but there is no run-time assembly compatible with arch.-x64.
error: System.Security.Cryptography.Encoding 4.0.0 provides a compile-time reference assembly for System.Security.Cryptography.Encoding on .NETCoreApp,Version=v1.0, but there is no run-time assembly compatible with arch.-x64.
error: System.Security.Cryptography.X509Certificates 4.1.0 provides a compile-time reference assembly for System.Security.Cryptography.X509Certificates on .NETCoreApp,Version=v1.0, but there is no run-time assembly compatible with arch.-x64.
error: System.Text.Encoding 4.0.11 provides a compile-time reference assembly for System.Text.Encoding on .NETCoreApp,Version=v1.0, but there is no run-time assembly compatible with arch.-x64.
error: System.Text.Encoding.Extensions 4.0.11 provides a compile-time reference assembly for System.Text.Encoding.Extensions on .NETCoreApp,Version=v1.0, but there is no run-time assembly compatible with arch.-x64.
error: System.Threading.Tasks 4.0.11 provides a compile-time reference assembly for System.Threading.Tasks on .NETCoreApp,Version=v1.0, but there is no run-time assembly compatible with arch.-x64.
error: System.Threading.Timer 4.0.1 provides a compile-time reference assembly for System.Threading.Timer on .NETCoreApp,Version=v1.0, but there is no run-time assembly compatible with arch.-x64.

error: One or more packages are incompatible with .NETCoreApp,Version=v1.0 (arch.-x64).

log  : Lock file has not changed. Skipping lock file write. Path: /home/patrick/.vscode/extensions/ms-vscode.csharp-1.2.0/coreclr-debug/project.lock.json

log  : /home/patrick/.vscode/extensions/ms-vscode.csharp-1.2.0/coreclr-debug/project.json
log  : Restore failed in 2175ms.

Error: 
Errors in /home/patrick/.vscode/extensions/ms-vscode.csharp-1.2.0/coreclr-debug/project.json

Error:     System.IO 4.1.0 provides a compile-time reference assembly for System.IO on .NETCoreApp,Version=v1.0, but there is no run-time assembly compatible with arch.-x64.
    System.Globalization.Calendars 4.0.1 provides a compile-time reference assembly for System.Globalization.Calendars on .NETCoreApp,Version=v1.0, but there is no run-time assembly compatible with arch.-x64.
    System.Globalization 4.0.11 provides a compile-time reference assembly for System.Globalization on .NETCoreApp,Version=v1.0, but there is no run-time assembly compatible with arch.-x64.
    System.Diagnostics.Tracing 4.1.0 provides a compile-time reference assembly for System.Diagnostics.Tracing on .NETCoreApp,Version=v1.0, but there is no run-time assembly compatible with arch.-x64.
    System.Diagnostics.Tools 4.0.1 provides a compile-time reference assembly for System.Diagnostics.Tools on .NETCoreApp,Version=v1.0, but there is no run-time assembly compatible with arch.-x64.
    System.Diagnostics.Debug 4.0.11 provides a compile-time reference assembly for System.Diagnostics.Debug on .NETCoreApp,Version=v1.0, but there is no run-time assembly compatible with arch.-x64.
    System.Console 4.0.0 provides a compile-time reference assembly for System.Console on .NETCoreApp,Version=v1.0, but there is no run-time assembly compatible with arch.-x64.
    System.Collections 4.0.11 provides a compile-time reference assembly for System.Collections on .NETCoreApp,Version=v1.0, but there is no run-time assembly compatible with arch.-x64.
    System.Diagnostics.Process 4.1.0 provides a compile-time reference assembly for System.Diagnostics.Process on .NETCoreApp,Version=v1.0, but there is no run-time assembly compatible with arch.-x64.
    System.Net.Http 4.1.0 provides a compile-time reference assembly for System.Net.Http on .NETCoreApp,Version=v1.0, but there is no run-time assembly compatible with arch.-x64.
    System.Security.Cryptography.Algorithms 4.2.0 provides a compile-time reference assembly for System.Security.Cryptography.Algorithms on .NETCoreApp,Version=v1.0, but there is no run-time assembly compatible with arch.-x64.
    System.IO.MemoryMappedFiles 4.0.0 provides a compile-time reference assembly for System.IO.MemoryMappedFiles on .NETCoreApp,Version=v1.0, but there is no run-time assembly compatible with arch.-x64.
    Microsoft.Win32.Primitives 4.0.1 provides a compile-time reference assembly for Microsoft.Win32.Primitives on .NETCoreApp,Version=v1.0, but there is no run-time assembly compatible with arch.-x64.
    System.IO.Compression 4.1.0 provides a compile-time reference assembly for System.IO.Compression on .NETCoreApp,Version=v1.0, but there is no run-time assembly compatible with arch.-x64.
    System.IO.FileSystem 4.0.1 provides a compile-time reference assembly for System.IO.FileSystem on .NETCoreApp,Version=v1.0, but there is no run-time assembly compatible with arch.-x64.
    System.Net.Primitives 4.0.11 provides a compile-time reference assembly for System.Net.Primitives on .NETCoreApp,Version=v1.0, but there is no run-time assembly compatible with arch.-x64.
    System.Net.Sockets 4.1.0 provides a compile-time reference assembly for System.Net.Sockets on .NETCoreApp,Version=v1.0, but there is no run-time assembly compatible with arch.-x64.
    System.Reflection 4.1.0 provides a compile-time reference assembly for System.Reflection on .NETCoreApp,Version=v1.0, but there is no run-time assembly compatible with arch.-x64.
    System.Reflection.Extensions 4.0.1 provides a compile-time reference assembly for System.Reflection.Extensions on .NETCoreApp,Version=v1.0, but there is no run-time assembly compatible with arch.-x64.
    System.Reflection.Primitives 4.0.1 provides a compile-time reference assembly for System.Reflection.Primitives on .NETCoreApp,Version=v1.0, but there is no run-time assembly compatible with arch.-x64.
    System.Resources.ResourceManager 4.0.1 provides a compile-time reference assembly for System.Resources.ResourceManager on .NETCoreApp,Version=v1.0, but there is no run-time assembly compatible with arch.-x64.
    System.Runtime 4.1.0 provides a compile-time reference assembly for System.Runtime on .NETCoreApp,Version=v1.0, but there is no run-time assembly compatible with arch.-x64.
    System.Runtime.Extensions 4.1.0 provides a compile-time reference assembly for System.Runtime.Extensions on .NETCoreApp,Version=v1.0, but there is no run-time assembly compatible with arch.-x64.
    System.Runtime.Handles 4.0.1 provides a compile-time reference assembly for System.Runtime.Handles on .NETCoreApp,Version=v1.0, but there is no run-time assembly compatible with arch.-x64.
    System.Runtime.InteropServices 4.1.0 provides a compile-time reference assembly for System.Runtime.InteropServices on .NETCoreApp,Version=v1.0, but there is no run-time assembly compatible with arch.-x64.
    System.Runtime.InteropServices.RuntimeInformation 4.0.0 provides a compile-time reference assembly for System.Runtime.InteropServices.RuntimeInformation on .NETCoreApp,Version=v1.0, but there is no run-time assembly compatible with arch.-x64.
    System.Security.Cryptography.Encoding 4.0.0 provides a compile-time reference assembly for System.Security.Cryptography.Encoding on .NETCoreApp,Version=v1.0, but there is no run-time assembly compatible with arch.-x64.
    System.Security.Cryptography.X509Certificates 4.1.0 provides a compile-time reference assembly for System.Security.Cryptography.X509Certificates on .NETCoreApp,Version=v1.0, but there is no run-time assembly compatible with arch.-x64.
    System.Text.Encoding 4.0.11 provides a compile-time reference assembly for System.Text.Encoding on .NETCoreApp,Version=v1.0, but there is no run-time assembly compatible with arch.-x64.
    System.Text.Encoding.Extensions 4.0.11 provides a compile-time reference assembly for System.Text.Encoding.Extensions on .NETCoreApp,Version=v1.0, but there is no run-time assembly compatible with arch.-x64.
    System.Threading.Tasks 4.0.11 provides a compile-time reference assembly for System.Threading.Tasks on .NETCoreApp,Version=v1.0, but there is no run-time assembly compatible with arch.-x64.
    System.Threading.Timer 4.0.1 provides a compile-time reference assembly for System.Threading.Timer on .NETCoreApp,Version=v1.0, but there is no run-time assembly compatible with arch.-x64.
    One or more packages are incompatible with .NETCoreApp,Version=v1.0 (arch.-x64).

dotnet exited with error code 1
abrodersen commented 8 years ago

@libratian Yes this is expected. We need to add the arch RID to the list of recognized RIDs in the CLI. I'm not sure where that code lives.

libratian commented 8 years ago

@abrodersen Hmm, a hacky solution may be the following: https://github.com/dotnet/coreclr/blob/master/build.sh#L40 There you could directly set the __DistroRid to something which is supported like ubuntu.14.04-x64. I tried to integrate this in your aur-package, but unfortunately I am new to this patchfiles etc, sorry.

leafi commented 8 years ago

Thought I posted this earlier; either my comment got deleted/eaten, or I've gone mad. Both possible.

In any case, the Arch Linux dotnet-cli package broke for me and at least a few others, due to gcc warning about 'ignoring return value of function declared with warn_unused_result' on the call to write in CoreCLR src/pal/src/exception/seh.cpp, the call to realpath in tests/src/Common/Platform/platformdefines.cpp, and the call to pipe2 in CoreFX src/Native/System.Native/pal_process.cpp all ignoring the return values.

I had a terrible patchset to fix the build using empty ifs (https://gist.github.com/leafi/9404f79bcd3c64e4d828c0c5e06f056d), but @abrodersen has integrated patches using the correct method - casting to (void).

(Feel free to use this knowledge & code however you want. These errors occurred using gcc-multilib 6.1.1-2, gcc-libs-multilib 6.1.1-2 and glibc 2.23-5. This is something to do with the whole -DFORTIFY_SOURCE=2 thing Arch does by default; e.g. write is declared in unistd.h with __wur, which is #defined as attribute_warn_unused_result if __USE_FORTIFY_LEVEL > 0. I do not know why me and some others have been getting this error, and others haven't.)

rbingham commented 8 years ago

Is there any update on this? I have been using the dotnet-cli package provided by @abrodersen for awhile now and things seem to be working correctly.

jaen commented 8 years ago

Is there anything I can do to help with getting this along? We're using dotnetcore at work for backend development and I would really appreciate being able to run (that works mostly okay) and debug (this – not so much) the project on my Arch system.

ravenwish1990 commented 7 years ago

Any updates? My interest is in VSCode-mssql, which needs this system to support Arch before even thinking about the idea of supporting Arch themselves...

janvorli commented 7 years ago

CC: @gkhanna79

gkhanna79 commented 7 years ago

CC @kouvel

aloisdg commented 7 years ago

I can find 3 packages on the aur. 2 are out of date. The last one is aur/dotnet-coreclr-git by aignas. I will try it.

Edit:

build failed.

bigolewannabe commented 7 years ago

I haven't had a chance to put it through all of it's paces but https://aur.archlinux.org/packages/dotnet-cli is working for me. I just spun up the default project with dotnet new dotnet restore dotnet build dotnet run and was able to run the default Hello World console app.

aloisdg commented 7 years ago

@bigolewannabe Do you have both C# and F#? If so, I will try this solution!

ghost commented 6 years ago

@davzucky, the AUR package for dotnet-sdk is available at https://www.archlinux.org/packages/community/any/dotnet-sdk/ (with latest SDK for .NET Core 2.0).

ghost commented 2 years ago

Due to lack of recent activity, this issue has been marked as a candidate for backlog cleanup. It will be closed if no further activity occurs within 14 more days. Any new comment (by anyone, not necessarily the author) will undo this process.

This process is part of our issue cleanup automation.

ghost commented 1 year ago

This issue will now be closed since it had been marked no-recent-activity but received no further activity in the past 14 days. It is still possible to reopen or comment on the issue, but please note that the issue will be locked if it remains inactive for another 30 days.