Runtime: FreeBSD 지원

https://github.com/dotnet/corefx/issues/1576 에 관한 한 합의가 있는 것 같습니다.

https://github.com/dotnet/corefx/issues/1625에 대한 결정도 내려지면 일부 코드를 배송할 수 있습니다.

MSFT가 달리 선택하지 않는 한 dotnet/runtime#14536에 대한 합의가 포트 팀에 의해 도달되었습니다. FreeBSD 입니다. 문제 dotnet/corefx#1999는 공개 API에 정의를 도입하는 문제가 될 수 있습니다.

MSFT가 달리 선택하지 않는 한, 포트 팀은 dotnet/runtime#14536에 대한 합의에 도달했습니다.

내가 그 권리를 읽으면 https://github.com/dotnet/corefx/pull/1999 가 병합될 때 이 MSFT가 새로운 공개 API를 승인하는 것으로 간주할 수 있으므로 MSFT 승인이 필요 없는 일반 풀 요청.

그렇다면 나에게 좋은 소리입니다.

https://github.com/dotnet/corefx/pull/1999#issuecomment -111279577에 따른 다음 단계는 다음과 같습니다.

1. "FreeBSD 포트 팀"은 CoreFX의 FreeBSD 버전을 만들기 위한 작업을 계속합니다(dotnet/corefx#1626에 의해 추적됨).
2. 포트 팀은 FreeBSD에서 CoreFX 단위 테스트 실행을 시작할 수 있도록 FreeBSD에서 CoreFX 및 CoreCLR 스택을 충분히 제공합니다.
3. 테스트는 최소한의 품질 수준에 도달합니다. 아직 이것이 어떻게 생겼는지 정확히 알지 못하지만 대부분의 테스트가 통과하는 것과 같은 것을 의미할 것으로 예상합니다. 이상적으로는 FreeBSD에 대해서만 특정 테스트를 비활성화하지 않는 것이 좋습니다(Linux 및 OSX와 비교하여 FreeBSD를 다른 *NIX 플랫폼보다 높은 표준으로 유지하고 싶지는 않습니다).
4. FreeBSD 포트 팀과 협력하여 CoreFX 팀은 FreeBSD에서 실행되는 CI 시스템에 CoreFX 테스트를 추가합니다.
5. 속성을 추가하는 문제 dotnet/runtime#14536에 기반한 PR 병합에 대해 논의합니다.

그것은 나에게 완전히 합리적인 계획처럼 들린다.

자, 그럼 corefx가 작동하도록 하는 작업을 시작하겠습니다.

FreeBSD에서 corefx를 구축하는 첫 번째 장애물은 모노인 것 같습니다. 빌드 스크립트는 버전 4.1이 필요하다고 주장합니다. @ajensenwaud 는 프랑크푸르트 호스트에서 이 작업을 수행했지만 얼마나 완전한지 잘 모르겠습니다.

지금은 빌드를 대기열에 넣고 출력이 어떻게 보이는지 확인하겠습니다.

편집: (모노) 빌드가 마지막에 다음 키커와 함께 충돌합니다.

Making all in mini
make[1]: "/usr/home/josteink/mono/mono/mini/Makefile" line 2906: warning: duplicate script for target "%.exe" ignored
make[1]: "/usr/home/josteink/mono/mono/mini/Makefile" line 2899: warning: using previous script for "%.exe" defined here
  CC       genmdesc-genmdesc.o
In file included from genmdesc.c:9:0:
mini.h:17:34: fatal error: ./mono/metadata/loader.h: Too many levels of symbolic links
 #include <mono/metadata/loader.h>
                                  ^
compilation terminated.
*** Error code 1

Stop.
make[1]: stopped in /usr/home/josteink/mono/mono/mini
*** Error code 1

Stop.

FreeBSD에서 corefx를 구축하는 첫 번째 장애물은 모노인 것 같습니다.

FWIW, 개인적으로 이것이 첫 번째 장애물이라고 생각하지 않습니다. 두 가지 빌드 관련 문제가 있습니다.

1. FreeBSD에서 올바르게 작동하는 어셈블리 빌드
2. FreeBSD에서 이러한 어셈블리 빌드

(1) 중요하며 이 문제가 무엇을 의미하는지 생각합니다. (2) 있으면 매우 좋지만, FreeBSD에서 관리되는 코드를 실행하기 위한 훌륭한 시스템을 만드는 것을 막지는 못합니다.

물론 적합하다고 생각되는 우선 순위를 자유롭게 지정할 수 있지만 제 추천은 (2)보다는 (1)에 집중하는 것입니다.

Linux에서 corefx를 빌드하고 OSX에서 빌드하는 데 여전히 문제가 있으므로 CI 시스템이 Windows에서 해당 플랫폼에 대한 어셈블리를 빌드하도록 합니다. 그런 다음 결과 어셈블리를 대상 플랫폼으로 셔틀하여 테스트를 실행합니다.

충분히 정당합니다. 나는 우리가 실제로 FreeBSD에서 직접 구축할 수 있다면 corefx에 구워진 일반적인 FreeBSD 플랫폼 지원을 얻는 것이 더 쉬울 것이라고 생각했습니다.

지금은 Windows에서 시작한 빌드를 처리하고 빌드 구성을 함께 수행하려고 합니다.

@josteink btw. corefx는 이제 Mono 4.0.1.44에서 빌드되어야 합니다.

@akoeplinger 니스. 그래서 FreeBSD에서도 실행할 수 있다는 희망이 생겼습니다. :)

좋은 점. 그러나 corefx가 FreeBSD 환경의 일부가 되기를 정말로 원한다면 소스에서 컴파일하여 포트 시스템으로 가져올 수 있어야 합니다.

Mono 4.0.1.44가 이러한 문제를 많이 수정한다고 들었지만 아직 다룰 시간이 없었습니다. 나는 포트 팀이 포트 Makefile을 업데이트하고 있으며 우리가 새로운 패치에 대해 이야기하고 있다는 것을 알고 있습니다.

2015년 6월 12일 20:21에 Stephen Toub [email protected] 은 다음과 같이 썼습니다.

FreeBSD에서 corefx를 구축하는 첫 번째 장애물은 모노인 것 같습니다.

FWIW, 개인적으로 이것이 첫 번째 장애물이라고 생각하지 않습니다. 두 가지 빌드 관련 문제가 있습니다.

FreeBSD에서 올바르게 작동하는 어셈블리 빌드
FreeBSD에서 이러한 어셈블리 빌드
(1) 중요하며 이 문제가 무엇을 의미하는지 생각합니다. (2) 있으면 매우 좋지만, FreeBSD에서 관리되는 코드를 실행하기 위한 훌륭한 시스템을 만드는 것을 막지는 못합니다.

물론 적합하다고 생각되는 우선 순위를 자유롭게 지정할 수 있지만 제 추천은 (2)보다는 (1)에 집중하는 것입니다.

우리의 CI 시스템이 Windows에서 해당 플랫폼에 대한 어셈블리를 빌드하도록 corefx build-on-Linux 및 build-on-OSX가 거의 없다는 점에 유의하십시오. 그런 다음 결과 어셈블리를 대상 플랫폼으로 셔틀하여 테스트를 실행합니다.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.

네, 저는 결코 동의하지 않습니다... Linux, OSX, FreeBSD에서 corefx를 _build_할 수 있다는 것은 중요합니다. 우선 순위 관점에서 Linux, OSX, FreeBSD에서 corefx를 실제로 _run_ 실행할 수 있는 것이 더 중요하다고 제안하는 것뿐입니다. :wink: 둘 다 병렬로 작업할 수 있다면 더 좋습니다.

@guntley ,
다음과 같습니다:쿨: 남아 있는 항목을 요약한 마크다운 작업 체크리스트가 있는 경우:

- [x] task 1
- [ ] task 2
- [ ] task 3

다음과 같이 렌더링합니다.

• [ ] 작업 1
• [ ] 작업 2
• [ ] 작업 3

이것은 아마도 다른 사람들이 그러한 업적을 달성하도록 장려할 것이며 FreeBSD 지원은 예상보다 훨씬 빨리 도착할 것입니다! :색안경:

내가 아는 한 FreeBSD 지원에는 CoreFX에서 다음 작업이 필요합니다.

• [x] 빌드 도구와 스크립트에 FreeBSD 플랫폼을 소개합니다. ( @josteink 와 저, PR dotnet/corefx#2021 병합, dotnet/corefx#2030 병합)

13 어셈블리는 자체적으로 컴파일되지 않으며 FreeBSD에 특정한 변경이 필요합니다. 대부분 Linux/OS X용으로 이미 존재하는 Interop 조각(빌드 출력의 발생순):

• [x] System.Private.URI (완료, PR dotnet/corefx#2032 병합)
• [x] System.Console (완료, PR dotnet/corefx#2031 병합)
• [x] System.Diagnostics.Debug (완료, PR dotnet/corefx#2039 병합)
• [x] System.Diagnostics.Process (토론 dotnet/corefx#2070, 홍보 dotnet/corefx#3257)
• [x] System.IO.Compression.ZipFile (완료, PR dotnet/corefx#2041 병합)
• [x] System.IO.FileSystem.DriveInfo (토론 dotnet/corefx#2526, 홍보 dotnet/corefx#2606)
• [x] System.IO.FileSystem.Watcher (토론 dotnet/corefx#2046, 홍보 dotnet/corefx#3257)
• [x] System.IO.FileSystem (완료, PR dotnet/corefx#2049 병합)
• [x] System.IO.MemoryMappedFiles (토론 dotnet/corefx#2527, 홍보 dotnet/corefx#3143)
• [x] System.IO.Pipes (토론 dotnet/corefx#2528, 홍보 dotnet/corefx#2974)
• [x] System.Net.NameResolution (토론 dotnet/corefx#2988, 홍보 dotnet/corefx#3471)
• [x] System.Security.Cryptography.Hashing.Algorithms (완료, PR dotnet/corefx#2040 병합)
• [x] System.Security.SecureString (완료, PR dotnet/corefx#2039 병합)
• [x] System.Runtime.Environment (dotnet/corefx#1999에 의해 차단됨)
• [x] System.Runtime.InteropServices.RuntimInformation (완료, PR dotnet/corefx#2068 병합)

열리고 병합된 PR을 기반으로 해당 목록을 업데이트하려고 합니다.

참고: PR dotnet/corefx#2039 병합

여기에서 앞서가려고 하는 것뿐입니다... System.IO.FileSystem.Watcher 어떻게 구현할 계획입니까?

Iirc FreeBSD에는 Linux 및 Windows와 같은 inotify 가 없습니다(이것이 지난번에 확인한 Dropbox가 없는 이유이기도 합니다). 이것이 문제의 잠재적인 원인이 될 것입니까? 아니면 이 문제를 해결하는 방법에 대한 아이디어가 있는 사람이 있습니까?

Stephen Toub가 다른 주제(https://github.com/dotnet/corefx/pull/2021#issuecomment-111602342)에서 제안한 대로 잠시 이를 스텁하고 PlatformNotSupportedException을 던질 것을 제안합니다. 그런 다음 최소한 완전한 어셈블리 세트가 있으며 추가 단계를 차단하지 않고 특정 문제에 대해 계속 작업할 수 있습니다.

그것에 대해 별도의 호를 열어 주시겠습니까?

System.IO.FileSystem.Watcher 토론을 dotnet/corefx#2046으로 이동합시다.

얘들아 System.Diagnostics.Process 그런 차단기가 있습니까?

@jasonwilliams200OK 는 오늘 아침 일찍 FreeBSD를 CheckPlatformTests 내의 FreeBSD 테스트는 dotnet/buildtools 가 업데이트될 때까지 취소되어야 했습니다.

• [ ] FreeBSD를 지원하도록 빌드 도구 업데이트 - https://github.com/dotnet/buildtools/pull/180
• [ ] [Fact,PlatformSpecific(PlatformID.FreeBSD)] 테스트를 CheckPlatformTests에 다시 적용 - https://github.com/dotnet/corefx/pull/2068#discussion_r32570244 및 https://github.com/dotnet/corefx/pull/2068#discussion_r32570244 참조
• [ ] https://github.com/dotnet/corefx/pull/2068에 public static OSPlatform FreeBSD 추가

@jasonwilliams200OK 지난 밤에 https://github.com/dotnet/corefx/issues/2070 으로 공식화된 gitter에서 System.Diagnostics.Process 에 대한 몇 가지 토론이 있었습니다.

@huntley , 감사합니다. 나는 실제로 그 메시지를 읽었다. System.Diagnostics.Process 는 까다롭습니다. AFAIK, io.js 팀은 FreeBSD 프로세스 관리에 대해 비슷한 문제를 겪었습니다. Mono 팀은 아마도 그것을 못 박았을 것이므로 @akoeplinger 및 co.인 경우 희망을 가지십시오. 이 문제에 대해 우리를 계몽할 수 있습니까? :)

시스템.IO.파일시스템.드라이브 정보

gitter에서 논의한 바와 같이 getmntinfo 의 기본 사용법을 살펴보았습니다.

#include <sys/param.h>
#include <sys/ucred.h>
#include <sys/mount.h>
#include <stdio.h>

int main() {
  struct statfs *mntbuf;
  int mntsize = getmntinfo(&mntbuf, MNT_NOWAIT);

  for( int i = 0; i < mntsize; i++ ) {
    printf("%s\n", mntbuf[i].f_mntonname);
  }
}

해당 샘플을 실행하면 다음과 같은 출력이 생성됩니다.

$ ./a.out
/
/dev
/tmp
/usr/home
/usr/ports
/usr/src
/var/crash
/var/log
/var/mail
/var/tmp
/dev/fd
/usr/compat/linux/proc
/proc
$

그래서 우리가 필요로 하는 일을 하는 것 같습니다. 문제는 결과에 대해 어떤 유형의 필터링을 수행해야 합니까?

DriveInfo 개체의 "의도"를 살펴보면 Windows 세계의 .NET에서 파일을 저장하거나 검색할 수 있는 위치를 열거하는 경우가 많습니다( C: , D: 등). 그러나 Unix 계층적 파일 시스템을 사용할 때 / 반환하면 이러한 요구 사항을 충족하기에 충분합니다.

그래서 우리는 무엇을 반환해야합니까? 무엇이 유용할까요? 유용하다고 생각해야 할까요?

Linux 버전은 무시하도록 설정된 것을 제외하고 모든 것을 덤프합니다.

https://github.com/dotnet/corefx/blob/master/src/System.IO.FileSystem.DriveInfo/src/System/IO/DriveInfo.Linux.cs#L98 -L99

다음 필터를 넣으려고 시도했지만 출력 측면에서 실제로 아무 것도 변경하지 않았습니다.

    if ((mntbuf[i].f_flags != MNT_IGNORE)) {
        printf("%s\n", mntbuf[i].f_mntonname);
    }

어떤 의견?

@josteink , 대단한 발굴! 를 기반으로 https://github.com/dotnet/corefx/issues/815#issuecomment -113825960 및 https://github.com/dotnet/corefx/issues/1729 , 우리가 가지고 올 @sokket과 협력해야한다고 생각 다른 Unices에서 작동하는 솔루션입니다.

Windows 드라이브 개념에서 가장 논리적인 매핑처럼 보이는 각 마운트 지점에 대한 정보를 얻기 위해 getmntinfo 및 statfs를 사용하는 OSX에서 실행 중인 버전이 있습니다. OSX의 함수 및 구조체 정의가 FreeBSD 정의와 일치하는지 다시 확인하고, 그렇다면 OSX에 대한 커밋이 BSD에서도 작동하는지 확인합니다.

내 PR @josteink에 당신을 추가

잘 들린다. 미리 알려주셔서 감사하고 FreeBSD도 사랑해주셔서 감사합니다.

나는 이러한 기능에 대한 몇 가지 기본적인 pinvoke를 조사했으며 모든 마샬링 및 변환을 직접 수행해야 하는 것처럼 보입니다. 따라서 다른 사람이 이미 노력을 기울인 경우 누가 거부할 수 있습니까? ;)

문제 없습니다...주요 차이점은 구조체 선언에 있었던 것 같습니다. 앞으로 이 문제를 더 많이 겪게 될 것이므로 많은 PInvoke 서명을 공유할 수 있도록 리팩토링을 하고 있습니다. 내 PR(오늘 또는 내일, 테스트 실행 방법에 따라)에 더 큰 설명을 추가할 것이지만 기본적으로 FreeBSD에 대한 PInvoke 서명과 구조체 서명(온라인에서 찾은 헤더 기반)을 추가하고 컴파일합니다. Mac에서 테스트했기 때문에 _should_(이론적으로는...) FreeBSD에서 작동합니다. 이는 단지 구조체 선언 변경이기 때문입니다. 하지만 사용자의 마일리지는 다를 수 있습니다. 그렇지 않은 경우 DriveInfo 클래스와 PInvokes 99%를 갖게 되며 FreeBSD 뉘앙스를 기반으로 약간의 조정이 필요합니다.

좋은 소식 @sokket. 포트 팀이 개발에 사용하는 컴퓨터에 계정을 만들었습니다. 유럽 기반이지만 항상 켜져 있고 메모리와 처리 능력이 풍부합니다. 바라건대 이것은 FreeBSD와 함께 작업할 때 도움이 되고 마찰을 제거하는 데 도움이 될 것입니다.

# ssh [email protected]

비밀번호 인증이 비활성화되었습니다. 키 중 하나를 사용

@josteink 도 문제 참조: https://github.com/dotnet/corefx/issues/815(Mac/FreeBSD 용 System.IO.FileSystem.DriveInfo)

업데이트가 있습니까? FreeBSD에서 나머지 어셈블리를 구현한 사람이 있습니까?

나는 나의 새로운 아기를 돌보기에 바빴고, 어디에서나 코딩할 시간이 없었습니다.

나는 이러한 문제가 잠복 상태에 있다고 의심했고 이것이 어느 정도 확인되었다고 생각합니다.

아직 구현되지 않은 어셈블리의 경우 위 목록에서 "구현 방법" 문제를 연결했습니다. 나머지 어셈블리를 구현하기 위한 노력을 조정하는 데 도움이 되기를 바랍니다.

나는 우리가 한 일과 장소를 추적하는 데 어려움을 겪고 있었다는 것을 인정해야 하므로 확실히 좋은 조치입니다. 잘 했어요 :)

어디에서 찾을 수 있습니까? 나머지 어셈블리를 얻는 것이 좋습니다.
구현.

15/07/25 22:10에 Jan Henke는 다음과 같이 썼습니다.

아직 구현되지 않은 어셈블리의 경우 "어떻게
위의 목록에서 "-문제를 구현합니다. 조정에 도움이 되길 바랍니다.
이러한 나머지 어셈블리를 구현하기 위한 노력.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/dotnet/corefx/issues/1626#issuecomment -124838781.

이 댓글은 https://github.com/dotnet/corefx/issues/1626#issuecomment -111800540입니다.

저는 지금 네이티브 shim이 완료되기를 기다리고 있습니다. 이러한 어셈블리가 FreeBSD에서 작동하도록 하는 대부분의 작업을 이 shim이 대신해야 하기 때문입니다.

@nguerrera 진행 상황을 계속 알려주시면 감사하겠습니다. :)

업데이트:
@janhenke 는 https://github.com/dotnet/corefx/pull/2974가 병합되어 System.IO.Pipes 가 FreeBSD에 빌드 됨을 확인했습니다! :색안경:

업데이트:
dotnet/corefx#2527 폐쇄, System.IO.MemoryMappedFiles 는 FreeBSD를 기반으로 합니다.
확인해주셔서 감사합니다 @janhenke !

shims 접근 방식 덕분에 shim이 FreeBSD에서 컴파일되는지 확인하기만 하면 됩니다. 고맙게도 삶이 훨씬 쉬워집니다. :)

dotnet/corefx#3257은 System.Diagnostic.Process 와 System.IO.FileSystem.Watcher 를 모두 가져와서 System.Net.NameResolution 미해결 상태로 남깁니다. (PR이 병합되고 FreeBSD에서 작동하면 언급된 두 어셈블리를 확인하겠습니다)

dotnet/corefx#3471에서 System.Net.NameResolution 가져와 위의 목록을 완성해야 합니다.

dotnet/corefx#3471이 방금 병합되었습니다 :)

@sokket , 업데이트에 감사드립니다. 이 가이드를 사용하여 FreeBSD에 마스터(f467911)를 구축했습니다: https://gist.github.com/jasonwilliams200OK/6efa7907e66275df2d24. 현재 차단기는 https://github.com/dotnet/buildtools/issues/292이며 업스트림에서 수정되었지만 다음 buildtools 롤아웃을 기다리고 있습니다. :)

업데이트: dotnet/buildtools#292에 대한 수정 사항이 포함된 새 빌드 도구가 CoreFX 마스터에 도착했습니다. buildtools의 다음 스토퍼는 https://github.com/dotnet/buildtools/issues/300입니다 . 테스트를 실행할 수 있는 OS 특정 도구가 없습니다.

@janhenke , System.Diagnostics.Process (#2070) 및 System.IO.FileSystem.Watcher (#2046)을 완료로 표시했습니다. 그러나 그것들은 구현되지도 않고 FreeBSD에서 컴파일되지도 않습니다. 관리 코드를 컴파일하여 실제로 목록을 확인했습니까?

커밋 60c78da3c918b0d256cc1f878de06d351dbe3342( msbuild.log 참조)에 대한 최근 경험에 따르면 다음 어셈블리는 컴파일되지 않습니다.

• 시스템.진단.프로세스
• 시스템.진단.프로세스매니저
• System.Diagnostics.ThreadInfo
• System.IO.FileSystemWatcher
• System.Net.SocketAddress _(좋아요, 이것은 최근에 추가되었습니다)_

내가 기억하는 한 관련 shim 컴파일을 확인했습니다. 관리되는 코드에는 FreeBSD 특정 코드가 없어야 하기 때문입니다. 언급한 shim은 위에 링크된 PR과 함께 shimed되어야 합니다.
그러나 나는 또한 그 사이에 전체 컴파일을 실행했습니다. 최소한 System.Diagnostics.ThreadInfo 및 System.IO.FileSystemWatcher 가 컴파일되었습니다. 그래서 뭔가 후퇴했을 것입니다.

언급한 shim은 위에 링크된 PR과 함께 shimed되어야 합니다.

사실 PR https://github.com/dotnet/corefx/pull/3257 은 shim과 관련이 없습니다. 관리되는 프로젝트(이전 접근 방식)에는 여전히 일부 PAL 코드가 있으므로 절대적으로 확인하려면 관리되는 어셈블리를 빌드해야 합니다.

사실 PR dotnet/corefx#3257은 shim과 관련이 없습니다.

나는 동의하지 않는다. P/Invoke 코드를 System.Native shim으로 리팩토링하고 있습니다. 또한 위에서 편집한 것처럼 그 사이에 컴파일된 어셈블리 중 적어도 일부를 기억하고 있습니다.

나는 동의하지 않는다

https://github.com/dotnet/corefx/pull/3257/files : .Linux.cs 대한 System.Diagnostics. .Unix.cs 및 .Linux.cs 인스턴스를 참조하십시오. .OSX.cs 는 변경되지 않았습니다.

P/Invoke 코드를 System.Native shim으로 리팩토링하고 있습니다.

예, System.Native 아래의 일반적인 도우미를 리팩터링하지만 System.Diagnostics.* et al은 아닙니다.

이러한 어셈블리가 System.* 라이브러리에 대한 P/Invoking뿐인 경우에도 그 중 일부(예: System.Diagnostics.Process 및 System.IO.FileSystem.Watcher)에 FreeBSD 작업이 필요할 수 있습니다. 그들은 Linux 및 OS X에 고유한 기능을 사용하고 있으며 기본 shim 뒤에 이를 추상화하려고 하지 않습니다. shim의 목표는 Unix를 위한 단일 관리 바이너리로 끝나는 것이 아닙니다. 비록 그것이 작업에서 올 때 매우 좋은 속성이지만; 주요 목표는 취약성을 유발하는 ABI 차이를 피하는 것입니다. FreeBSD 바이너리도 필요한 Linux/OS X 전용 바이너리가 최소한 소수의 어셈블리에 계속 있을 것으로 예상합니다.

참고로 System.Diagnostics.ProcessManager라는 corefx 어셈블리는 없습니다.
시스템.진단.스레드 정보,
System.IO.FileSystemWatcher 또는
시스템.넷.소켓 주소. 다른 어셈블리의 형식입니다.

FreeBSD 바이너리도 필요한 Linux/OS X 전용 바이너리가 최소한 소수의 어셈블리에 계속 있을 것으로 예상합니다.

이는 Alpine 지원과 같은 Linux를 대상으로 하는 Solaris 및 non-glibc(musl 및 μlibc)가 도착할 때마다 별도의 바이너리를 갖게 된다는 것을 의미합니까? 그리고 다른 아키텍처 ARM, MIPS, RISC, SPARC 등은 다른 수준의 분리가 필요합니까?

가능한 한 많이 POSIX 인터페이스/시스템 호출로 수렴하고 동일한 바이너리에서 사용할 구성(CMake를 통해)을 사용하여 차이점을 기능 감지하는 것이 합리적이지 않습니까(크기/성능에 영향을 미치지 않는 한) 상당히 어셈블리)? 내가 이해한 바와 같이 System.Native.so 바이너리에는 다른 특정 System.*.Native.so 대한 공통 도우미가 있으며 이는 관심사 분리 원칙 준수에 충분해 보입니다. 그러나 System.Net.Http.FreeBSD.ARM.Native.so 또는 System.Net.Http.Solaris.SPARC.so 되면 "움직이는 부분이 너무 많음" 등으로 관리하기가 매우 어렵습니다.

명명된 corefx 어셈블리가 없습니다.

좋은 지적. 나는 실제로 msbuild 로그의 실패 인스턴스와 .OSX.cs 및 .Linux.cs 파일의 수를 보고 있었습니다. :웃다:

가능한 한 POSIX 인터페이스/시스템 호출로 수렴하는 것이 합리적이지 않을까요?

우리는하다. POSIX를 통해 파일 보기를 잘 하는 것을 어떻게 제안합니까? POSIX를 통해 프로세스 열거를 잘 할 것을 어떻게 제안합니까?

그러나 System.Net.Http.FreeBSD.ARM.Native.so 또는 System.Net.Http.Solaris.SPARC.so로 변환되면 "움직이는 부분이 너무 많음" 등으로 인해 관리하기가 매우 어렵습니다.

나는 이것을 이해하지 못한다. 기본 .so 파일의 요점은 각 대상 플랫폼에 대해 서로 다른 기본 바이너리를 가져오지만 이름이 System.Whatever.Platform.ext가 아니라 System.Whatever.ext라는 것입니다. 컴파일러가 동일한 일반 논리를 취하고 해당 플랫폼에 특정한 정의와 함께 사용할 수 있도록 합니다. 이는 각 플랫폼에 동일한 기호가 있는 경우에만 작동합니다. 컴파일러는 inotify를 사용하도록 작성된 코드를 마술처럼 취하지 않고 다른 시스템의 파일 감시 인터페이스와 함께 작동하도록 허용하지 않습니다. 일반적으로 우리는 의미 있는 곳에서 표준화된 API를 사용하려고 열심히 노력했지만 그러한 API가 존재하지 않거나 잘 표준화되지 않았거나 더 나은 플랫폼별 솔루션이 있는 곳에서는 더 나은 플랫폼을 사용했습니다. 특정 솔루션, 예를 들어 Linux에서 프로세스 열거를 위해 procfs 사용, Linux에서 파일 시스템 감시를 위해 inotify 사용 등. 이러한 플랫폼별 로직이 관리 코드 또는 네이티브 코드에 있는지 여부는 이식의 용이성에서 실제로 중요하지 않습니다. 새로운 플랫폼이 등장할 때 기존 API가 작동하면 기존 솔루션도 작동하고 작동하지 않는 경우 해당 플랫폼에 대한 새 솔루션을 작성해야 합니다. 그래서 우리는 대상 API가 이식 가능한 곳에서 관리 코드를 훨씬 더 이식 가능하게 만드는 1:1 shim에 대해 네이티브를 사용하여 관리 코드에서 가능한 한 많은 작업을 수행하려고 했습니다. 우리는 네이티브 코드에서 #ifdef를 사용하여 작은 세부 사항을 설명했습니다. 어떤 플랫폼의 이 API가 다른 플랫폼의 해당 API와 충분히 가깝지만 전체 솔루션이 완전히 다른 것으로 확장되지는 않습니다. 그 시점에서 추상화는 관리되는 API가 되고 우리는 각 시스템에 대해 다른 관리되는 구현을 수행합니다.

FreeBSD가 Linux처럼 inotify를 노출하거나 OS X처럼 EventStream을 노출하는 경우 해당 OS API가 shim 뒤에 있을 때 shim은 FreeBSD와 쉽게 작동하도록 만들 수 있으며 동일한 관리 바이너리를 FreeBSD에서 사용할 수 있습니다. FreeBSD가 이러한 API를 노출하지 않으면 FreeBSD에서 사용할 수 있는 일부 파일 감시 솔루션을 사용하여 System.IO.FileSystem.Watcher의 사용자 정의 구현을 작성해야 합니다. System.Diagnostics.Process에 대한 유사한 설명입니다. 파일 감시를 위한 코드가 shim에 있는지 여부는 그것에 거의 영향을 미치지 않습니다.

계획은 이러한 모든 기본 API가 결국 shim 뒤로 이동하는 것입니다. 그러나 이식성이 좋지 않기 때문에 우선 순위와는 거리가 멀고 모든 곳에서 노출되는(또는 노출되어야 하는) libc의 API로 시작하는 것을 보셨을 것입니다.

POSIX를 통해 파일 보기를 잘 하는 것을 어떻게 제안합니까?

inotify는 Linux 전용이므로 모든 POSIX를 수행할 수는 없습니다. FreeBSD/OSX는 별도의 구현을 제공합니다.

제안:

기본 바이너리 배포 관점에서 모든 OS는 이름은 같지만 기능이 다른 동일한 바이너리 세트를 받아야 합니다.

다음은 제안된 구조입니다.

# cmake

check_include_files( "inotify.h" HAVE_INOTIFY_ABILITY )

// config.h.in
cmakedefine01 COREFX_HAVE_INOTIFY_ABILITY
// always a good idea to prefix our headers with project id :)

// header (pal_fsw.hpp) file

#pragma once

class file_system_watcher_shim
{
public:
  void common_function_for_posix_compliants();
  void slightly_diverged_function();
  void painfully_diverged_watch_function();
}

// source (pal_fsw_commons.cpp) file

#include "pal_fsw.hpp"

void file_system_watcher_shim::common_function_for_posix_compliants() {
 // TODO: implement common function for all
}

void file_system_watcher_shim::slightly_varied_function() {

#if COREFX_HAVE_XYZ_ABILITY

  // your way

#else

  // my way

#endif // COREFX_HAVE_XYZ_ABILITY

}

// source (pal_fsw_inotify.cpp) file

// this is a separate compilation unit and will clash with others,
// therefore guarding it with preprocessor directive

#if COREFX_HAVE_INOTIFY_ABILITY

#include "pal_fsw.hpp"

void file_system_watcher_shim::painfully_diverged_watch_function() {
 // TODO: implement inotify based watcher
}

#endif // COREFX_HAVE_INOTIFY_ABILITY

// source (pal_fsw_non_inotify.cpp) file

// this is a separate compilation unit and will clash with others,
// therefore guarding it with preprocessor directive

#if !COREFX_HAVE_INOTIFY_ABILITY

#include "pal_fsw.hpp"

void file_system_watcher_shim::painfully_diverged_watch_function() {
 // TODO: implement non-inotify way
}

#endif // !COREFX_HAVE_INOTIFY_ABILITY

이것은 본질적으로 우리가 가지고 있는 것입니다. 예를 들어

• "common_function_for_posix_compliants"는 공유 Unix 관리 바이너리의 논리에서 사용되는 기본적으로 시밍된 1:1 함수입니다.
• "slightly_diverged_function"은 공유 Unix 관리 바이너리의 논리에서 사용되는 일부 기본 #ifdef가 있는 거의 1:1 기능으로 기본적으로 시밍됩니다.
• "painfully_diverged_watch_function"은 플랫폼별 관리 바이너리의 논리에서 사용되는 기본적으로 1:1 기능으로 시밍됩니다.

실제 차이점은 "고통스럽게 분기된" 논리를 구현하는 코드가 C#에서 수행되는지 C++로 수행되는지 여부이며 우리는 C#을 선택했으며 이미 모두 C#으로 구현되었습니다. 왜 그런 경우에 C++로 모두 다시 작성하는 것이 훨씬 더 설득력 있는 옵션이 될 것인지에 대한 설득력 있는 주장을 보지 못했습니다.

@jasonwilliams200OK 오늘 모노 업데이트로 FreeBSD 자체에 corefx를 다시 빌드합니다. 마지막으로 빌드한 이후로 많은 새로운 오류 메시지가 있습니다.
Interop.Libc 가 결국 사라질지 궁금합니다.

@stephentoub 모든 것은 포장에 달려 있습니다. 네이티브 부분에 모든 플랫폼별 코드가 있으면 모든 Unix 계열 플랫폼에 대해 하나의 관리되는 어셈블리가 있다는 이점이 있습니다.
게다가, 저는 우리가 이러한 "플랫폼 종속 관리 코드에 대한 일반 구현이 필요하다고 강력히 생각합니다. 단지 NotImplementedExcption을 던지더라도. 그렇게 하면 최소한 모든 것을 즉시 컴파일한다면 새 플랫폼으로 훨씬 쉽게 이식할 수 있습니다. 또한 최소한 지원되지 않는 플랫폼에서 실행을 시도할 수 있는 기회.
일반적으로 적어도 즉시 성공적으로 컴파일할 수 있다면 훨씬 쉽습니다.

@stephentoub , C++와 C#을 섞어서 죄송합니다. 이제 네이티브 레이어가 진입점(네이티브 라이브러리 기능 또는 시스템 호출)을 노출하고 IO 및 관리 코드를 삭제하는 것이 플랫폼별 래핑된 유틸리티 메서드/래핑된 시스템 호출을 소비할 것인지 결정하는 곳이라는 것을 이해합니다. 게다가, (네이티브 및 관리) 티어 모두 POSIX가 아닌 기능을 사용해야 하는 OS에 독립적일 수 없습니다.

@janhenke , 동의합니다. 나는 또한 우리가 말하는 동안 마스터를 구축하고 있습니다. 또 다른 반복되는 어셈블리 서명 문제가 있습니다.

CSC : error CS7027: Error signing output with public key from file '/root/corefx/packages/Microsoft.DotNet.BuildTools.1.
0.25-prerelease-00104/lib/ECMA.snk' -- mscoree.dll [/root/corefx/src/System.IO.Compression.ZipFile/ref/System.IO.Compres
sion.ZipFile.csproj]
CSC : error CS7033: Delay signing was specified and requires a public key, but no public key was specified [/root/corefx
/src/System.IO.Compression.ZipFile/ref/System.IO.Compression.ZipFile.csproj]

CSC : error CS7027: Error signing output with public key from file '/root/corefx/packages/Microsoft.DotNet.BuildTools.1.
0.25-prerelease-00104/lib/ECMA.snk' -- mscoree.dll [/root/corefx/src/System.IO.Compression/ref/System.IO.Compression.csp
roj]
CSC : error CS7033: Delay signing was specified and requires a public key, but no public key was specified [/root/corefx
/src/System.IO.Compression/ref/System.IO.Compression.csproj]

곧 전체 msbuild.log 요지 링크를 게시할 예정입니다.

게다가 이러한 "플랫폼 종속 관리 코드"에 대한 일반 구현이 필요하다고 강력하게 생각합니다.

나는 동의한다. 부분 클래스 대신 추상 기본 클래스에서 공통 및 대부분 공통 가상 메서드로 상속을 사용하고 필요한 경우 "대부분 공통/부분적으로 다른"에 대해 재정의할 수 있습니다. 그런 다음 각 OS마다 완전히 다른 추상 메서드를 구현합니다. 이 접근 방식을 사용하면 전문화/일반화가 DRY'를 잃는 경우 다단계 상속 조상을 고용할 수 있습니다. 그러나 마지막으로 확인했을 때 CoreFX에서 부모-자식 연결보다 부분 클래스가 선호되었습니다(어떤 이유로 기억나지 않음). :)

다음은 커밋 2d36889에 대한 msbuild.log입니다.

https://gist.githubusercontent.com/jasonwilliams200OK/b375ce52c7b0c90e24af/raw/c895d405a3044dd6acdb26ec49c4b0ced0c76d1a/corefx-msbuild.log

/cc: @akoeplinger

@jasonwilliams200OK 왜 그렇게 복잡

일부 어셈블리가 FreeBSD용으로 빌드/작동할 수 없다는 사실이 나머지 어셈블리를 테스트하기 위한 주요 방해 요소가 되어야 한다고 생각하지 않습니다. 보류 중인 작업(FileSystemWatcher, Process, Networking)이 있는 항목은 FreeBSD에서 실행되는 빌드 및 테스트에서 건너뛰도록 해야 합니다. 그런 다음 이미 작동하는 것에서 회귀를 방지하는 프로세스를 갖는 동안 개별적으로 가져올 수 있습니다.

나는 일부 어셈블리가 FreeBSD를 위해 빌드/작동할 수 없다는 사실이 나머지 어셈블리를 테스트하기 위한 주요 장애물이 되어야 한다고 생각하지 않습니다.

동의

보류 중인 작업(FileSystemWatcher, Process, Networking)이 있는 빌드 및 테스트 실행에서 FreeBSD를 건너뛰도록 해야 합니다.

또는 @janhenke가 제안한 것과 유사하게 PlatformNotSupported를 발생시키는 파일로

@ellismg 최근 변경 사항(#3684)을 사용하여 이전 방법을 단순화하여 테스트를 실행할 수 있습니다(https://github.com/dotnet/coreclr/issues/1633#issuecomment-143669303).

• https://gist.github.com/jasonwilliams200OK/6efa7907e66275df2d24 (특히 기본 shim을 별도로 빌드하는 단계 _after_ 상태 1로 build.sh 종료) 후 CoreCLR 아티팩트 zip: cd /root; curl -o bins.zip "http://dotnet-ci.cloudapp.net/job/dotnet_coreclr/job/debug_freebsd/lastSuccessfulBuild/artifact/*zip*/archive.zip (잊지 마세요 URL 주위에 따옴표) unzip bins.zip; chmod -R 0777 archive/; rm bins.zip; cd corefx .

(Windows 시스템에서 필요하지 않음)

• 테스트를 실행했습니다.

./run-test.sh \ --coreclr-bins ../archive/bin/Product/FreeBSD.x64.Debug \ --mscorlib-bins ./packages/Microsoft.DotNet.CoreCLR/1.0.0-prerelease/lib/aspnetcore50 \ --corefx-native-bins ./bin/FreeBSD.x64.Debug/Native

그것은 말한다:

40 테스트 실패

일부 어셈블리가 FreeBSD용으로 빌드/작동할 수 없다는 사실이 나머지 어셈블리를 테스트하기 위한 주요 방해 요소가 되어야 한다고 생각하지 않습니다.

나는 이것에 동의해야합니다. 테스트를 시작하기 전에 모든 작업이 완료될 때까지 기다리는 것보다 우리가 수행한 작업에 대해 QA를 시작하는 것이 좋습니다.

그것은 말합니다: 40개의 테스트가 실패했습니다

몇 개 중에 40개? 우리는 어떤 야구장에 있습니까? :)

몇 개 중에 40개? 우리는 어떤 야구장에 있습니까? :)

나도 때린다. 테스트가 테스트 어셈블리(관리되는 dll)에서 생성되고 총 테스트 수가 표시되지 않습니다.

스크립트가 마지막에 생성하는 숫자는 실패한 테스트 어셈블리의 수입니다. xUnit은 어셈블리당 실패한 테스트 수를 실행의 일부로 stdout에 기록해야 합니다. 숫자는 각 테스트 어셈블리 폴더에서 생성하는 XML 파일에도 있어야 합니다.

런타임도 충돌할 수 있으며 이 경우 테스트 어셈블리당 로그가 생성되지 않을 수 있습니다.

@jasonwilliams200OK 어셈블리 서명 문제에 진전이 있었는지 아십니까? 나는 우분투에서 같은 것을 치고 있습니다. 아무도 그것에 대해 작업하지 않는다면 아마도 우리는 그것에 대해 별도의 문제를 열어야 할 것입니다.

@naamunds , CoreFX 마스터에서 https://github.com/dotnet/corefx/issues/3739의 일부로 수정되었습니다

업데이트 - 오늘 저는 FreeBSD에서 테스트를 실행했는데 수천 개의 테스트가 통과했고 일부는 System.Diagnostics.Process 및 친구의 명백한 부족으로 인해 실패했습니다. ~40분의 성공적인 실행 후 System.IO.FileSystem 테스트에서 중단되었습니다(종료하기 위해 Ctrl+C를 누르기 전 약 15분 동안).

@jasonwilliams200OK 어떻게 freebsd에서 corefx를 컴파일할 수 있었습니까? gssapi에 대한 오류가 발생했습니다.

@sec , https://gist.github.com/jasonwilliams200OK/6efa7907e66275df2d24 , GSSAPI는 CoreFX에 필요하지 않았습니다. 그러나 pkg가 최근 FreeBSD로 이식된 것 같습니다: http://www.freshports.org/security/p5-GSSAPI. pkg upgrade pkg && pkg update && pkg install p5-GSSAPI 을(를) 시도할 수 있습니다.

@jasonwilliams200OK , 나는 이미 이것을 얻었습니다(perl ext. btw입니다.) 문제는 gssapi_ext.h가 누락되었습니다. 트릭은 "pkg install krb5"를 수행하는 것이 었습니다. 이제 네이티브 컴파일됩니다.
coreclr 런타임에 복사했지만 여전히 ASP.NET Core 앱을 실행할 수 없습니다. 그러면 싸움이 계속됩니다.

이 작업의 현재 상태는 무엇입니까? @janhenke 의 목록이 완전하고 정확합니까? 수행해야 할 모든 작업이 완료되었습니까? 그럼 닫아야겠죠?

그렇다면 왜 우리에게 이 작업이 남아 있습니까? https://github.com/dotnet/corefx/issues/2070

아직 할 일이 있다면 현 상황을 기준으로 새로운 이슈를 등록해야 할까요?

이것도 필요하다고 생각합니다 - dotnet/corefx#2046

현재 상황에 따라 새로운 문제를 등록해야 합니까?

예 :+1:

우리는 모두이 일에 관심을 표명 @RussellHaley 및 @wfurt (FreeBSD의 커뮤니티) (.NET에서 코어 팀)와 FreeBSD를위한 지역 사회 중심의 포트를 논의했다.
다음은 우리가 함께 만든 계획 제안입니다(피드백/제안 환영).

1. FreeBSD를 대상으로 하는 CoreCLR 및 CoreFX 리포지토리에서 바이너리 생성 - 해킹을 사용하는 것은 괜찮습니다.
   
   
   
   • 병렬화하기 어렵습니다. @wfurt 가 작업할 것입니다.
   
   
   • 빌드는 FreeBSD를 대상으로 하는 다른 플랫폼(Mac, Linux)의 빌드를 혼합할 수 있습니다.
   
   
   • FreeBSD 관련 버그 수정으로 빌드를 재현하려면 문서화된 단계(FreeBSD wiki에서)가 필요합니다.
   
   
2. CoreCLR 테스트 실행 및 안정화(corerun 사용)
   
   
   
   • 테스트는 다른 플랫폼에서 구축될 수 있습니다.
   
   
   • 목표: 런타임의 기본 품질 제공
   
   
3. CoreFX 테스트 실행 및 안정화(corerun 사용)
   
   
   
   • 테스트는 다른 플랫폼에서 구축될 수 있습니다.
   
   
   • 여기에는 xunit이 필요합니다. 우리는 과거 포팅 경험을 바탕으로 [2]가 완료되면 xunit이 제대로 작동할 것이라고 믿습니다.
   
   
   • 이것은 이론적으로 [2]와 병렬화될 수 있습니다. xunit 바로 가기가 필요할 수 있습니다(예: 다른 플랫폼에서 정적 실행 레시피 생성)
   
   
4. FreeBSD에서 전체 스택 빌드([1]-[3]의 부트스트래퍼로 corerun 사용)
   
   
   
   • .NET Core를 부스트래핑하려면 모든 도구(nuget, msbuild, roslyn)가 필요합니다.
   
   
5. 설치 프로그램(FreeBSD 포트)
   
   
   
   • 1단계: 너겟 피드의 제품 바이너리 사용
   
   
   • 2단계: 소스에서 제품 빌드(소스에서 빌드 작업에서 차단됨)
   
   
   • FreeBSD 커뮤니티 전문 지식과 설계에 대한 지침이 필요합니다.
   
   
   • 참고: 커뮤니티 지원 패키지로 공식 .NET Core 다운로드 페이지에서도 FreeBSD 패키지를 연결할 수 있습니다.
   
   
6. FreeBSD에서 정기적인 빌드 및 테스트 실행
   
   
   
   • 목표: FreeBSD를 깨는 .NET Core 리포지토리의 변경 사항을 조기에 알려야 합니다.
   
   
   • 필요한 디자인
   
   
   • FreeBSD 커뮤니티 전문 지식과 설계에 대한 지침이 필요합니다.
   
   

작동 원리:

• [2]-[4]의 변경은 주로 CoreCLR/CoreFX 리포지토리에서 수행되어야 합니다(CLA 서명 요구 사항, .NET Core 팀 전문가/구성원의 코드 검토 등으로 인해).
• 우리는 이 문제에 대한 높은 수준의 작업을 추적할 것입니다. 특정 버그는 별도의 문제로 제출됩니다.

도움이 필요한 사람이 있으면 여기에서 알려주십시오. [1]과 충분히 멀리 떨어져 있으면 위의 [2]와 [3]에서 작업 항목을 쉽게 배포할 수 있습니다.

제안서의 최신 버전은 이번 호의 맨 위에 있습니다.

freebsd-mono 목록에 관심을 표명한 더 많은 사람들 태그하기( 이 스레드 ): @smortex @radovanovic @Echo-8-ERA

BTW: Mathieu Prevot GitHub 계정을 찾을 수 없습니다 -- [업데이트] https://github.com/dotnet/corefx/issues/1626#issuecomment -330348424에서 찾을 수 있습니다: @mprevot

NetBSD의 경우 강력한 posix 뮤텍스가 누락되었으며, 이는 명명된 로버스 뮤텍스를 생성하기 위해 아직 누락된 유일한 기능입니다. 이제 LLDB/NetBSD를 사용하여 관리 코드 오류를 디버그할 수 있습니다. 코어 파일에서 잘 작동합니다. 이전 시도에서 LLDB에 이 기능이 없어서 죽었습니다(이 디버거를 .NET용으로 이식하기 시작했습니다).

더 나은 FreeBSD 지원이 있으면 큰 도움이 될 것입니다.

과거에는 NetBSD 빌드봇을 CI 시스템에 연결하고 패치를 확인하기 위한 Hyperv 게스트 지원이 부족하여 문제가 있었습니다... 이를 위해 MS의 도움이 필요할 수 있습니다. 나는 그것을 실행하는 데 필요한 독점 소프트웨어가 있을 것으로 예상합니다. 저는 소유하지 않습니다... NetBSD 재단과 Microsoft 사이에 공동 관심(투자)이 있다면 그 일을 할 개발자를 찾을 수 있을 것입니다.

"강력한 posix 뮤텍스"는 어디에 있습니까? .NET Core PAL의 일부입니까?

어떤 CI 시스템을 말씀하시는 건가요? .NET Core 포트 노력과 관련된 이유는 무엇입니까?

"강력한 posix 뮤텍스"는 어디에 있습니까?

NetBSD 커널(및 libc/libpthread)에서 이것은 CoreCLR의 일부입니다. FreeBSD는 지난 2년 동안 이를 개발했습니다. 최신 안정 릴리스에서 사용 가능할 수도 있지만.. 확인이 필요합니다.

.NET 이식을 다시 시작하기 전에 이 기능을 추가하고 싶습니다. (네트워크 라우팅을 위한 작은 누락 API도 감지되었습니다. 하지만 지금은 건너뜁니다.)

.NET Core PAL의 일부입니까?

코드를 확인하지 않고 지금은 기억이 나지 않습니다. 이것은 강력한 뮤텍스(또는 아마도 세맵토어)라는 .NET을 구현하는 데 사용되는 API입니다.

어떤 CI 시스템을 말씀하시는 건가요?

넷BSD.

.NET Core 포트 노력과 관련된 이유는 무엇입니까?

지난번에 보니 옵션 기능이었습니다. 커널 인터페이스 및 유틸리티(예: LLDB)에서 기능 패리티를 사용하기로 결정했습니다. 기능적인 빌딩 블록을 얻고 나중에 집을 짓는 것이 내 스타일의 작업입니다. 어느 시점에서 우리는 어쨌든 그것을 필요로 할 것이므로 한 번에 개발하지 않는 이유는 무엇입니까? 이해 주셔서 감사합니다 :)

아마도 GH에서 freebsd-dotnet 그룹에 태그를 지정할 수 있습니까? 그는 그곳의 회원입니다(또는 그의 계정 이름을 조회할 수 있습니다). 이메일은 [email protected]입니다.

[편집] @karelz의 이메일 수신 및 이전 회신 삭제

@RussellHaley 가 적절하다고 생각하는 경우 더 큰 그룹에 자유롭게 태그를 지정하십시오. 나는 그의 이름이나 이메일을 통해 Mathieu의 GH 계정을 찾을 수 없었습니다. 그것이 내가 위에서 의미한 바입니다(BTW: 나는 이메일로 직접 그를 ping했습니다).

그룹에 태그를 지정하는 방법을 살펴보겠습니다.

다음은 Mathieu의 계정입니다. 아마도 개인 정보 설정?

https://github.com/mprevot

건배,

러스

2017년 9월 18일 월요일 오후 1:01 Karel Zikmund [email protected]
썼다:

@RussellHaley https://github.com/russellhaley 자유롭게 태그
적절하다고 생각하는 경우 더 큰 그룹. Mathieu의 GH를 찾을 수 없습니다.
그의 이름이나 이메일을 통해 계정, 그것이 내가 위에서 의미한 것입니다.

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/dotnet/corefx/issues/1626#issuecomment-330338996 또는 음소거
스레드
https://github.com/notifications/unsubscribe-auth/ACENF_N6mtOo3fptvku-LUMioNpZG7coks5sjswWgaJpZM4EPG-N
.

여기에서 언급된 곳을 볼 수 없지만 여기에서 목표로 하는 FreeBSD의 가장 낮은 버전은 무엇입니까?
(나는 또한 mono @freebsd 메일링 리스트에서 어떤 토론이 일어나야 하는지, 그리고 여기서 무엇을 해야 하는지 약간 혼란스럽습니다.)

음, Fedora가 계속된다면 MS는 현재 지원되는 버전, 즉 10.3(곧 10.4) 및 11.1만 지원할 것입니다.

@radovanovic FreeBSD 9는 더 이상 지원되지 않습니다. 10은 2018년 4월에, 11은 2021년에 EoL입니다. 내 경험에 따르면 11 대 10(원하는 경우 9도)에서 컴파일하는 데 문제가 없어야 합니다. FreeBSD는 이전 버전과의 호환성을 염두에 두고 개발되었습니다.

@radovanovic 나는 또한 mono@freebsd 메일링 리스트에서 어떤 토론이 일어나야 하는지, 그리고 여기서 무엇을 해야 하는지 약간 혼란스럽습니다.

여기가 mono@freebsd 메일링 리스트보다 더 많은 청중을 대상으로 하기 때문에 여기에서 기술적인 논의, 작업 조정 및 상태를 기대했습니다. OTOH 우리는 한 문제에 대해 무수히 많은 무작위 토론을 하고 싶지 않습니다. 따라서 합리적인 응답 수 이상으로 증가하면 이 문제와 별개의 문제로 특정 설계 토론을 할 수 있습니다.

마침내 FreeBSD 11.0에서 corefx 테스트를 실행할 수 있었습니다(외부 루프 테스트 없이)
총 통과: 144208
총 실패: 2622
건너뛴 합계 207

지침과 함께 https://github.com/dotnet/corefx/wiki/Building-.NET-Core--2.x-on-FreeBSD 를 업데이트하겠습니다. 특정 문제를 제출하고 os-freebsd 및 up-for-grab으로 태그를 지정하겠습니다.
본격적인 전투를 시작할 수 있습니다. 자원 봉사자가 필요합니다.

그리고 예, 제안된 2단계를 건너뛰었습니다. 나는 또한 그것에 대해 다시 갈 것이다.

일부 작업 진행 중인 변경 사항으로 현재 통계는 다음과 같습니다.
총 통과: 238892
총 실패: 58
건너뛴 합계 1628

System.Runtime.Tests.dll, 1
System.Net.Ping.Functional.Tests.dll, 7
System.Net.NameResolution.Pal.Tests.dll, 3
System.Net.NameResolution.Functional.Tests.dll, 4
System.IO.MemoryMappedFiles.Tests.dll, 1
System.IO.FileSystem.Tests.dll, 7
System.Globalization.Tests.dll, 2
System.Drawing.Common.Tests.dll, 31
System.Console.Tests.dll, 2

깨진 컵 지원을 추적하기 위해 dotnet/corefx#24538이 열립니다.

큰 진전! 트리 내에서 FreeBSD를 지원하는 경우 NetBSD를 추가하는 것은 간단해야 합니다.

@wfurt 이메일 주소를 공유해 주세요. 몇 줄

초기 지원이 마스터 분기에 병합되었습니다. 빌드는 WIKI 페이지에 설명된 대로 작동해야 합니다.
dotnet/corefx#24386에서 천천히 진행 중이지만 대부분의 사용자를 방해해서는 안 됩니다.

FreeBSD에서 이미 .NET을 부트스트랩할 수 있습니까?

한동안 @krytarowski를 시도하지 않았습니다. 툴링을 2.0 릴리스로 업데이트

안녕하세요, 그래서 clr 관리 테스트가 실행되지 않아 곤경에 처했습니다. https://pastebin.com/B5KhtKX5

얼마 동안 문제가 되었기 때문에 어떤 입력이든 좋을 것입니다. 또한 최근에 Windows(마스터, Git 개정 749194e)에서 corefx 빌드 시 빌드 오류가 발생했습니다. https://pastebin.com/JXUySLTY

나는 그것이 간헐적 인 문제라고 생각하지만 오늘 밤에 속도가 느려졌습니다.

오류를 보면:

tests/runtest.sh: line 786: ((: i<: syntax error: operand expected (error token is "<")

그리고 문제가 되는 코드 줄 :

bash for (( i=0; i<$maxProcesses; i++ )); do

내 직감은 $maxProcesses 가 정의되지 않아 불완전한 부울 표현식으로 이어진다는 것입니다.

diff +for (( i=0; i<$maxProcesses; i++ )); do -for (( i=0; i<; i++ )); do

이것은 상당히 테스트 가능해야 합니다. 그리고 그런 경우에는 어떻게 해서 이렇게 되었는지 알아보기 위해 뒤로 사냥을 가야 합니다.

당신의 도움을 주셔서 감사합니다! @josteink :) 맞습니다. 패치는 여기: https://pastebin.com/d5y9k1tw

이렇게 하면 테스트를 실행할 수 있지만 ~1000개의 오류에서 모두 동일한 특성을 포기했습니다.

실패 - JIT/방법론적/캐스트/iface/_il_dbgiface2/_il_dbgiface2.sh
실행 시작
/usr/home/russellh/Git/coreclr/bin/tests/Windows_NT.x64.Debug/Tests/coreoverlay/corerun _il_dbgiface2.exe
coreclr_initialize 실패 - 상태: 0x80004005
예상: 100
실제: 255
실행 종료 - 실패

좋아, @janvorli 의 매우 훌륭한 정보에

https://github.com/dotnet/coreclr/issues/1419

패치는 여기: https://pastebin.com/d5y9k1tw

깨진 빌드를 수정하는 패치가 있는 경우 모든 사람이 수정할 수 있도록 풀 요청으로 보내는 것이 좋습니다. :)

감사합니다. 나는 여전히 테스트를 실행하기 위해 노력하고 있으며 어젯밤 후속 오류의 원인이 무엇인지 확신할 수 없었습니다.

Netcore 2.1(출시 후)에 대한 Freebsd 11 "pkg install" 지원은 일어나지 않을 것이라고 생각합니다. 맞습니까?

TLDR; 많은 작업이 완료되었지만 집에 데려다 줄 사람이 필요합니다. 포트 Makefile을 작성하는 것은 쉬운 부분입니다.

@wfurt 는 Linux를 사용하여 CLR과 FX를 빌드할 수 있었지만 대부분 테스트되지 않았습니다. FreeBSD에서 빌드할 '네이티브' 부분을 얻을 수 있었지만 관리되는 부분을 Windows(FreeBSD용)에서 빌드하는 데 지연이 있었습니다. 모든 것이 운영 체제 간에 파일을 전송하는 엉망이었습니다.

[email protected] 메일링 리스트와 별도로 @dragonsa 는 Linux 에뮬레이션을 사용하여 MintOS에서 Dot Net Core 1의 바이너리 버전과 모든 도구 체인(msbuild, nuget 등)을 가져왔습니다. 나는 그의 패치를 사용하고 일부 도구를 실행할 수 있었지만 아무 것도 만들지 못했습니다. 이 패치가 아직 커밋되었는지 확실하지 않습니다. 나는 그들을 검토하는 도중에 직업을 옮겼습니다. 현재 역할에 DotNet이 없으며 지금 다른 일을 하고 있습니다.

그게 다 무슨 뜻이야? 누군가가 @dragonsa 의 패치를 확인할 수 있다면 포트 트리를 푸시할 수 있으며 기술적으로 FreeBSD에서 기본적으로 코어 2를 구축하는 것이 가능합니다. 하지만 보시다시피, 함께 가져와 정리해야 하는 작은 부분이 많이 있습니다. 내가 공을 떨어뜨렸으니 누군가가 그것을 집어들어야 한다. 나는 [email protected] 메일링 리스트에 뛰어드는 것을 제안한다. https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/eresources-mail.html

@russellhadley Russell을

안녕하세요,

여기에서 .NET 개발자와 이에 대해 논의하면서 FreeBSD 포트/패키지의 개발을 돕고 싶습니다.

전체 공개: 저는 .NET 개발자가 아니지만 이것을 트리에 포함시키기 위해 누구와도 함께 일할 의향이 있습니다.

~시

@cschuber 너무 바빠서 현 상황을 주시하지 마침내 우리가 이 물건이 제대로 착륙하는 것을 보십시오. 전폭적인 지지를 받고 있습니다 :)

@cschuber , 현재 활성 문제는 https://github.com/dotnet/coreclr/issues/18067입니다. 주로 이 네 가지 기능이 남아 있습니다 . label:os-freebsd+label :up-for-grabs+is:issue 가장 까다롭고 힘든 것 https://github.com/dotnet/corefx/issues/2046.

@cschuber 제안에 감사드립니다. 가능할 수 있는 시점에 거의 도달했습니다.
우리는 최근에 @mateusrodrigues 와 함께 FreeBSD에서 .net이 작동하도록 하고 있으며 그는 PowerShell을 작동시키려고 노력하고 있습니다. @kasper3에서 보낸 목록은 기본적으로 누락된 기능입니다. 지금은 PNSP를 던질 수 있다고 생각합니다. 내 장래의 가장 시급한 문제는 dotnet/corefx#30698 및 https://github.com/dotnet/coreclr/issues/18481입니다. 커뮤니티의 누군가가 그것들을 파헤칠 수 있다면 좋을 것입니다. 최근에 테스트를 해보지 않았지만 실패 횟수가 늘어날까 두렵습니다.
우리는 각각의 새로운 실패 그룹에 대해 문제를 열어야 합니다.

또한 소스 빌드를 수정하기 시작하지만 아직 몇 가지 과제가 있습니다.
C# 컴파일러는 C#으로 작성되었습니다. 현재 .net 빌드는 이전 버전의 .net을 사용하여 관리되는 어셈블리를 생성합니다. 또한 Nuget의 패키지에 따라 다릅니다.
현재 FreeBSD에서 coreclr, corefx 및 기타 저장소를 구축할 수 있을 만큼 충분한 부트스트랩 cli가 있습니다. 2.1 변경 사항 및 소스 빌드를 반영하기 위해 아직 빌드 지침을 업데이트하지 않았습니다.

+1 아직 약간의 추진력이 있어서 다행입니다. 움직이는 부분이 너무 많아서 따라가기가 어렵지만 사람들이 발전하고 있는 것 같습니다. 얼마 전에 https://github.com/dotnet/coreclr/issues/6115를 만들었지만 작업하던 프로젝트가 보류되었습니다. 언젠가 (리눅스 호환 없이) pkg install dotnet && dotnet build 만큼 쉽기를 바랍니다.

이것도 기대된다

이제 일일 빌드가 진행 중입니다. 여기에서 런타임 또는 SDK를 얻을 수 있습니다. https://dotnetcli.blob.core.windows.net/dotnet/Runtime/master/dotnet-runtime-latest-freebsd-x64.tar.gz 및
https://dotnetcli.blob.core.windows.net/dotnet/Sdk/master/dotnet-sdk-latest-freebsd-x64.tar.gz

예를 들어 Linux 또는 Windows에서 dotnet publish -r freebsd-x64 를 수행하면 자체 포함된 FreeBSD 응용 프로그램을 만들 수 있습니다.

아직 불완전하고 지원되지 않지만 누구나 쉽게 기여할 수 있어야 합니다.
사람들이 시도해 보고 문제를 보고할 수 있다면 좋을 것입니다.
또한 이것은 기능 격차를 좁히고 버그를 수정하기 위한 최종 푸시를 위한 좋은 시간이 될 것입니다.

참조: @mateusrodrigues

수고하셨습니다. @wfurt 와 @bartonjs.

2-3년 전쯤에 제가 첫 FreeBSD 커밋을 제안했을 때, 저는 실제로 우리가 여기까지 올 것이라고 믿지 않았지만 확실히 시도하고 싶었습니다.

이것은 확실히 큰 이정표이며 새로운 기여자가 포트를 완료하는 데 더 쉽게 도움이 되기를 바랍니다.

여기까지 올 수 있도록 도와주신 모든 분들께 진심으로 감사드립니다 👍

큰 진전! 나는 여전히 툴체인(LLDB 및 LLD를 제외한 대부분의 LLVM 프로젝트가 완료됨)과 NetBSD용 하드웨어 지원 가상화(Linux/BSD는 이제 VTx 치명적인 예외가 발생할 때까지 부팅을 시작하고 FreeDOS와 같은 더 간단한 OS는 이미 작동함)와 싸우고 있으므로 다시 시작하겠습니다. 내 NetBSD 포팅이 더 빨리 이루어지길 바랍니다. 더 나은 FreeBSD 지원은 더 쉬운 이력서에 도움이 될 것입니다.

엄청난 :)

우리는 술 취함을 축하합니다 왜 ensil bombsrdment??

@krytarowski 'FreeBSD 지원'이 더 나은 방법을 개발할 수 있습니까?

일부 FreeBSD 전문가가 https://github.com/dotnet/coreclr/issues/22124를 살펴볼 수 있다면 좋을 것입니다. 11용 바이너리 빌드가 12에서 실행될 것으로 예상하지만 그렇지 않은 것 같습니다 ;(
간단한 앱으로 재현하기 쉽고 12.0 릴리스는 dotnet이 의존하는 것을 깨는 것 같습니다.

안녕하세요, 저는 전문가는 아니지만 Lua53 포트의 12-RELEASE에서 스레딩 회귀를 발견했습니다.
원래 버그는 여기를 참조하십시오: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235158
확인된 기본 시스템 버그는 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235211입니다 (기본 시스템 버그는 비교를 위해 문제를 재현하는 데 사용할 수 있는 코드를 식별합니다).

Lua에 대한 수정 사항은 -pthread에 대한 Lua의 요구 사항이 ZERO인 경우에도 -pthread에 대한 링크입니다.

@RussellHaley 감사합니다. 그것은 유망한 리드처럼 보입니다.

도움이 될 수 있어 기쁩니다. 같이 놀고 싶지만 Lua 포트를 유지 관리하는 데 필요한 몇 시간이 거의 없습니다. 앞으로도 힘써주세요!

coreclr 에서 FreeBSD 스레딩 구현 을 전반적으로 꽤 일관되게 사용

즉, "일반" 스레드를 사용하여 만질 필요가 없는 기본 버트와 조각이 있을 수 있습니다.

일반적인 구현에 대해 더 많이 알고 있는 다른 사람이 참여할 수 있습니까? @janvorli ?

이렇게 하면 문제가 해결됩니다.

[furt<strong i="6">@daemon</strong> ~]$ LD_PRELOAD=/usr/lib/libpthread.so ./dotnet-3.x/dotnet --info
.NET Core SDK (reflecting any global.json):
 Version:   3.0.100-preview-010021
 Commit:    d5c97b7c2a

Runtime Environment:
 OS Name:     FreeBSD
 OS Version:  12
 OS Platform: FreeBSD
 RID:         freebsd-x64
 Base Path:   /usr/home/furt/dotnet-3.x/sdk/3.0.100-preview-010021/

Host (useful for support):
  Version: 3.0.0-preview-27218-01
  Commit:  d40b87f29d

.NET Core SDKs installed:
  3.0.100-preview-010021 [/usr/home/furt/dotnet-3.x/sdk]

.NET Core runtimes installed:
  Microsoft.NETCore.App 3.0.0-preview-27218-01 [/usr/home/furt/dotnet-3.x/shared/Microsoft.NETCore.App]

To install additional .NET Core runtimes or SDKs:
  https://aka.ms/dotnet-download

광범위한 테스트를 하지는 않았지만 적어도 dotnet 다시 실행할 수 있습니다.

좋아, dotnet 실행 파일이 Linux 이외의 다른 시스템용 pthread와 연결되어 있지 않음을 알 수 있습니다.
https://github.com/dotnet/core-setup/blob/2ef0b64810530961f492c33d37fc7509128e0a9b/src/corehost/cli/exe.cmake#L59 -L61

이 문제를 해결하는 방법이 말처럼 간단하다는 뜻입니까? 즉, 이렇게 간단합니까? https://github.com/josteink/core-setup/commit/25657ba2e181cce401acd7f4bf9d27a08a668470

그렇다면 기꺼이 홍보하겠습니다.

네 그렇게 생각합니다. @jooperator의 확인을 기다리고
"dl"도 필요한지 확실하지 않지만 PR @josteink 를 제출하면 해결할 수 있습니다.

오른쪽. 내 잘못이야. 다음과 같이 더 많이 : https://github.com/josteink/core-setup/commit/a08f38e25a98c25f59c8ed8c8567a0cb08b1c1c6

나는 그것에 대한 PR을 만들었습니다. 수정이 필요한 경우 알려주세요: https://github.com/dotnet/core-setup/pull/5072

오른쪽. 내 잘못이야. 다음과 같이 더 많이: josteink/ core-setup@a08f38e

나는 그것에 대한 PR을 만들었습니다. 수정이 필요한 경우 알려주세요: dotnet /core-setup#5072

참고로 이것은 기본 시스템에서 이미 패치된 것 같습니다. https://reviews.freebsd.org/D18988

dotnet/coreclr#22124 의 주요 문제가
FreeBSD 12.0에 독립형 앱을 게시하려고 할 때만 문제가 있습니다.

freebsd-x64 공식 NuGet 패키지는 .NET Core 3.0 미리 보기 2 이후 제거되었으며 그 이후로 FreeBSD용 앱을 게시할 수 없습니다. 3.0에서 다시 활성화할 계획이 있습니까?

슬프게도 FreeBSD 불러오기의 우선 순위를 낮춰야 했으며(종단 간 Azure 지원의 다양한 이유와 어려움으로 인해) .NET Core 3.0에서는 우선 순위가 아닙니다.
지금의 상태에서 세미 작업 상태로 유지하고 싶지만 지금은 투자할 시간이 많지 않습니다 :(.

@karelz 회신에 감사드리며 .NET Core 3.0의 우선 순위 작업을 이해합니다. 그런 다음 FreeBSD Linux 에뮬레이션으로 내 앱을 실행하는 데 중점을 둘 것입니다. :)

@hjc4869 아니면 모노로

다시 시도해 볼 계획이지만 @karelz가 언급했듯이 3.0에서는 우선 순위가 아닙니다.

@newsash Mono는 저에게 적합한 옵션입니다. 그러나 기존 .NET Core csproj 파일에 추가된 모노 대상으로 프로젝트를 빌드하기가 어려웠습니다.

Linux 컴퓨터에서 TargetFrameworks에 net472를 추가하고 FrameworkPathOverride 변수를 설정하려고 시도했지만 제대로 작동하지 않았습니다. 모노 및 .NET Core 모두에서 구현되지만 .NET Framework에서는 구현되지 않는 API를 사용하는 경우 모노로 빌드하지 못합니다. 게다가 모노는 .NET Standard 2.1을 지원하지만 여전히 net472 csproj에서 .NET Standard 2.1 dll에 대한 참조를 추가할 수 없습니다.

dotnet 도구를 사용하는 대신 별도의 csproj를 추가하고 mono msbuild를 사용해야 하나요? 아니면 문제에 대한 제안 사항이 있습니까?

간단한 설명입니다.

최근 발표[1]에 따라 .NET 5가 모노를 삼키려고 하므로 FreeBSD에 대한 적절한 지원을 제공하는 것이 시급해졌습니다.

Mono는 크로스 플랫폼 지원이 매우 우수하며 FreeBSD 포트에서 문제 없이 구축할 수 있음이 입증되었습니다. FreeBSD에는 고유한 기능이 많기 때문에 많은 상점에서 .net 로드를 FreeBSD에서 실행합니다. 지금까지 mono는 그 격차를 메워왔지만 .NET 5에서는 가까운 장래에 mono가 NET 5로 병합되고 FreeBSD 커뮤니티가 .NET 생태계에서 완전히 차단될 것 같습니다.

Dotnet은 이러한 일이 발생하기 훨씬 전에 성숙한 FreeBSD 지원을 제공해야 합니다.

Microsoft는 이 시점에서 공식적으로 FreeBSD를 지원하고 모든 dotnet 도구가 이 플랫폼에서 빌드되도록 해야 한다고 생각합니다.

@jasonpugsley 는 https://github.com/jasonpugsley/core-sdk/wiki/.Net-Core-3.0.0-for-FreeBSD 지침을 작성하고 @joperator 는 https://github에서 소스 빌드 작업을 수행하려고 합니다

corefx에 대한 마지막 ~30개의 테스트가 실패했습니다.

System.Diagnostics.Tests.ProcessTests.TestPeakWorkingSet64
System.Diagnostics.Tests.ProcessTests.TestPrivateMemorySize
System.Diagnostics.Tests.ProcessTests.Kill_ExitedNonChildProcess_DoesNotThrow(killTree: True)
System.Diagnostics.Tests.ProcessTests.TotalProcessorTime_PerformLoop_TotalProcessorTimeValid
System.Diagnostics.Tests.ProcessTests.Kill_EntireProcessTree_True_EntireTreeTerminated
System.Diagnostics.Tests.ProcessTests.TestPeakVirtualMemorySize
System.Diagnostics.Tests.ProcessTests.ProcessNameMatchesScriptName
System.Diagnostics.Tests.ProcessTests.TestPrivateMemorySize64
System.Diagnostics.Tests.ProcessTests.LongProcessNamesAreSupported
System.Diagnostics.Tests.ProcessTests.TestPeakWorkingSet
System.Diagnostics.Tests.ProcessTests.TestPeakVirtualMemorySize64
System.Diagnostics.Tests.ProcessTests.Kill_ExitedChildProcess_DoesNotThrow(killTree: True)
System.Diagnostics.Tests.ProcessTests.Kill_EntireProcessTree_True_CalledOnTreeContainingCallingProcess_ThrowsInvalidOperationException
System.IO.Tests.DirectoryInfo_MoveTo.MoveDirectory_FailToMoveLowerCaseDirectoryWhenUpperCaseDirectoryExists
System.IO.Tests.FileInfo_Exists.LockedFileExists
System.IO.Tests.FileStream_LockUnlock.OverlappingRegionsFromOtherProcess_ThrowsException(fileLength: 10, firstPosition: 0, firstLength: 10, secondPosition: 1, secondLength: 2)
System.IO.Tests.FileStream_LockUnlock.OverlappingRegionsFromOtherProcess_ThrowsException(fileLength: 10, firstPosition: 3, firstLength: 5, secondPosition: 3, secondLength: 5)
System.IO.Tests.FileStream_LockUnlock.OverlappingRegionsFromOtherProcess_ThrowsException(fileLength: 10, firstPosition: 3, firstLength: 5, secondPosition: 3, secondLength: 4)
System.IO.Tests.FileStream_LockUnlock.OverlappingRegionsFromOtherProcess_ThrowsException(fileLength: 10, firstPosition: 3, firstLength: 5, secondPosition: 4, secondLength: 5)
System.IO.Tests.FileStream_LockUnlock.OverlappingRegionsFromOtherProcess_ThrowsException(fileLength: 10, firstPosition: 3, firstLength: 5, secondPosition: 2, secondLength: 6)
System.IO.Tests.FileStream_LockUnlock.OverlappingRegionsFromOtherProcess_ThrowsException(fileLength: 10, firstPosition: 3, firstLength: 5, secondPosition: 2, secondLength: 4)
System.IO.Tests.FileStream_LockUnlock.OverlappingRegionsFromOtherProcess_ThrowsException(fileLength: 10, firstPosition: 3, firstLength: 5, secondPosition: 4, secondLength: 6)
System.IO.Tests.Directory_Move.MoveDirectory_FailToMoveLowerCaseDirectoryWhenUpperCaseDirectoryExists
System.Net.NameResolution.Tests.GetHostEntryTest.Dns_GetHostEntry_HostString_Ok(hostName: \"\")
System.Net.NameResolution.Tests.GetHostEntryTest.Dns_GetHostEntryAsync_HostString_Ok(hostName: \"\")
System.Net.NameResolution.Tests.GetHostByNameTest.DnsObsoleteBeginEndGetHostByName_EmptyString_ReturnsHostName
System.Net.NameResolution.Tests.GetHostByNameTest.DnsObsoleteGetHostByName_EmptyString_ReturnsHostName
System.Net.NetworkInformation.Tests.PingTest.SendPingAsyncWithIPAddressAndTimeoutAndBufferAndPingOptions_Unix(addressFamily: InterNetwork)
System.Net.NetworkInformation.Tests.PingTest.SendPingWithIPAddressAndTimeoutAndBufferAndPingOptions_Unix(addressFamily: InterNetwork)
System.Net.Sockets.Tests.DualModeAcceptAsync.AcceptAsyncV4BoundToSpecificV4_Success
System.Tests.AppDomainTests.MonitoringIsEnabled
System.Tests.GCExtendedTests.GetGCMemoryInfo

@am11 은 System.Diagnostics.Tests.ProcessTests를 보고 있으므로 잠금 테스트 실패가 가장 큰 차이로 보입니다. 누구든지 dotnet/corefx#30899를 살펴볼 수 있다면 좋을 것입니다.

이것에 대한 업데이트가 있는지 아니면 중단되었는지 궁금하십니까?

@elfalem , 요즘 FreeBSD CI 레그(Ubuntu에서 크로스 컴파일)가 dotnet/runtime PR에서 실행되고 있습니다. 모든 사전 요구 사항이 설치된 https://github.com/dotnet/dotnet-buildtools-prereqs-docker/ 의 도커 이미지를 사용합니다. 동일한 도커 컨테이너를 사용하여 로컬 또는 원격 시스템에서 런타임 패키지(기본적으로 tar.gz)를 게시할 수 있습니다. 예를 들어 https://github.com/am11/runtime/blob/feature/freebsd/ci/.github/workflows/main.yml 과 같은 포크 브랜치 중 하나에서 GitHub 작업을 설정할 수 있습니다. 이는 아티팩트를 업로드합니다. 태그 푸시 https://github.com/am11/runtime/releases/tag/6.0.0-dev.freebsd.1 에서 GitHub 릴리스로 dotnet-runtime-6.0.0-dev-freebsd-x64.tar.gz 아카이브에는 게시된 dotnet 애플리케이션(dotnet SDK가 있는 다른 linux/mac 시스템에서)을 실행하기에 충분한 비트가 있습니다. 나는 새로운 12.2 VM(vagrant)을 만들어 테스트했고, 공개된 앱을 Mac에서 VM으로 추출하여 복사했는데, 작동했습니다.

#!/usr/bin/env tcsh

$ sudo pkg install libunwind icu libinotify

$ fetch https://github.com/am11/runtime/releases/download/6.0.0-dev.freebsd.1/dotnet-runtime-6.0.0-dev-freebsd-x64.tar.gz
$ mkdir ~/.dotnet
$ tar xzf dotnet-runtime-6.0.0-dev-freebsd-x64.tar.gz -C ~/.dotnet

$ set PATH=(~/.dotnet:$PATH)
$ setenv PATH "$PATH"

$ dotnet /vagrant/MyPublishedApp.dll
Hello World!

@Thefrank 는 어느 시점에서 적절한 FreeBSD 포트 패키지를 만드는 방법을 찾고 있었습니다.

이것에 대한 업데이트가 있는지 아니면 중단되었는지 궁금하십니까?

https://github.com/dotnet/source-build/issues/1139 를 보고 싶을 수도 있습니다.
최근 dotNET5 final을 기다리면서 시도하지 않았지만 몇 달 전만 해도 FreeBSD 런타임은 Linux에서 크로스 컴파일로만 빌드할 수 있었습니다. ASPNet 및 SDK도 Linux 크로스 컴파일이 필요했지만 별이 정렬된 경우에만 빌드됨(아케이드 업데이트 또는 일부 다른 자동화된 봇이 종속성을 깨뜨리지 않음)

편집: 그리고 @am11 은 내가 심야 횡설수설을 입력하는 동안 더 나은 글을 게시했습니다. 그것을 읽고 내 것이 아니라
edit2: 구두점을 잊어버렸고 final이 2일 전에 나온 것 같습니다. 나는 이것 또는 무엇인가에 대해 작업해야 한다고 생각한다

위의 모든 것 외에도 https://github.com/dotnet/runtimelab/ 에서 FreeBSD 프로젝트를 만들었으며 패키지를 빌드하고 게시하는 작업을 천천히 진행하고 있습니다. 목표는 앱이 FreeBSD에서 실행되고 소스 빌드를 위한 시드를 가질 만큼 충분히 빌드하고 게시하는 것입니다.

빠른 업데이트를 작성해야겠다고 생각했습니다. 마침내 FreeBSD에서 5.0.0 RTM을 구축하기 위해 모든 행성을 정렬했습니다. 나는 Preview3 이후로 따라가지 못했고 성공적인 5.0을 얻기 위해 호환 가능한 빌드의 올바른 조합을 찾는 데 시간이 걸렸습니다(그리고 _많은_ 빌드 시도).
나는 놀랍게도 적은 수의 해킹으로 PowerShell 7.1.0을 빌드할 수 있었습니다. 완전히 테스트하지는 않았지만 작동하지만 SDK의 좋은 테스트인 것 같습니다.
방금 AspNetCore를 구축했지만 아직 테스트하지 않았습니다.

$ dotnet --info
.NET SDK (reflecting any global.json):
 Version:   5.0.100
 Commit:    5044b93829

Runtime Environment:
 OS Name:     FreeBSD
 OS Version:  11
 OS Platform: FreeBSD
 RID:         freebsd.11-x64
 Base Path:   /tmp/rtm/sdk/5.0.100/

Host (useful for support):
  Version: 5.0.0
  Commit:  cf258a14b7

.NET SDKs installed:
  5.0.100 [/tmp/rtm/sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 5.0.0 [/tmp/rtm/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 5.0.0 [/tmp/rtm/shared/Microsoft.NETCore.App]

To install additional .NET runtimes or SDKs:
  https://aka.ms/dotnet-download
$ dotnet new console
The template "Console Application" was created successfully.

Processing post-creation actions...
Running 'dotnet restore' on /tmp/test/test.csproj...
  Determining projects to restore...
  Restored /tmp/test/test.csproj (in 106 ms).
Restore succeeded.

$ dotnet run
Hello World!
$

$ LANG=en-US ./pwsh
PowerShell 7.1.0
Copyright (c) Microsoft Corporation.

https://aka.ms/powershell
Type 'help' to get help.

PS /tmp/powershell> $PSVersionTable

Name                           Value
----                           -----
PSVersion                      7.1.0
PSEdition                      Core
GitCommitId                    7.1.0
OS                             FreeBSD 11.4-RELEASE FreeBSD 11.4-RELEASE #0 r362094: Fri Jun 12 18:27:15 UTC 2020     [email protected]:/usr/obj/usr/src/sys/GE…
Platform                       Unix
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

PS /tmp/powershell> Get-Host

Name             : ConsoleHost
Version          : 7.1.0
InstanceId       : fa711f95-926c-47e4-9e0c-dff0f518f825
UI               : System.Management.Automation.Internal.Host.InternalHostUserInterface
CurrentCulture   : en-US
CurrentUICulture : en-US
PrivateData      : Microsoft.PowerShell.ConsoleHost+ConsoleColorProxy
DebuggerEnabled  : True
IsRunspacePushed : False
Runspace         : System.Management.Automation.Runspaces.LocalRunspace


PS /tmp/powershell>

이 작업을 수동으로(즉, CI 시스템 외부에서) 수행할 때의 유일한 문제는 다음 빌드에서 사용할 특정 빌드를 필요로 하는 주요 변경 사항으로 인해 발생하는 문제입니다. 자주 발생하지는 않지만 올바른 커밋을 찾기 위해 많은 시행착오가 필요합니다. CI 시스템에서 Linux 크로스 빌드를 하면 문제가 해결되지만 아직 살펴보지는 않았습니다. 그래도 완전한 SDK를 빌드한 다음 해당 SDK를 사용하여 다른 것을 빌드할 수 있다는 것을 아는 것이 좋습니다.

russellh<strong i="5">@freebird</strong>:/www/winlua_net/htdocs/downloads$ pkg search dotnet
linux-dotnet-cli-2.0.7         Cross-platform .NET implementation
linux-dotnet-runtime-2.0.7     Cross-platform .NET implementation
linux-dotnet-sdk-2.1.201       Cross-platform .NET implementation (Software Development Kit)
linux-dotnet10-runtime-1.0.11  Cross-platform .NET implementation
linux-dotnet10-sdk-1.1.9       Cross-platform .NET implementation (Software Development Kit)
linux-dotnet11-runtime-1.1.8   Cross-platform .NET implementation

좋은 진전입니다 @jasonpugsley. 빌드에 대한 더 나은 답변을 찾으려고 노력하고 있지만 지난 몇 달 동안 상당한 시간을 할애할 수 없었습니다 ;(
PowerShell이 ​​terminfo 때문에 당신에게 어떤 슬픔을 안겨주었습니까, 아니면 다른 곳에서 터미널 정의를 복사했습니까?

내가 ssh를 보낸 Mac에서 터미널 정의를 가져왔습니다.

@jasonpugsley 당신은 나보다 훨씬 앞서 있습니다. linux cross freebsd에서 코어 및 sdk 빌드. 제한된 테스트에서 잘 실행됩니다. 런타임이나 sdk 크로스빌드 모두 freebsd 자체에서 빌드할 수 없습니다(linux와 freebsd는 llvm9와 clang9를 사용하고 있습니다).
ld: error: /root/runtime/artifacts/obj/coreclr/FreeBSD.x64.Release/src/dlls/dbgshim/dbgshim.exports:1: unknown directive: V1.0
이번 주말에 시간이 더 있으면 조금 더 찔러보고 적어도 freebsd용 Linux에 aspnetcore를 구축할 수 있는지 확인하십시오.

@Thefrank , 당신은 무엇을 의미합니까?

$ ROOTFS_ENV="ROOTFS_DIR=/crossrootfs/x64"
$ DOTNET_DOCKER_TAG="mcr.microsoft.com/dotnet-buildtools/prereqs:ubuntu-18.04-cross-freebsd-11-20201109180854-f13d79e"
$ docker run -e $ROOTFS_ENV -v $(pwd):/runtime $DOTNET_DOCKER_TAG /runtime/build.sh -c Release -cross -os freebsd

실패하거나 artifacts/packages/Release/Shipping/dotnet-runtime-5.0.0-dev-freebsd-x64.tar.gz 의 바이너리 실행에 실패했습니까?
우분투 18 또는 20에 SDK 5 배를 crosscompile하려는 경우, 당신은이 패치를 적용 할 수 있습니다 https://github.com/dotnet/sdk/commit/80e42f16422352f725d78be72071781d8365a238를 (가 마스터 분기에이다).

반쯤 잠이 들면 포스팅을 그만해야겠어요.
런타임 및 SDK 빌드는 Linux에서 완료됩니다.
이러한 바이너리는 freebsd(dotnet --info, 새 콘솔 및 실행)에서 실행됩니다.
이러한 바이너리는 freebsd의 소스에서 런타임 또는 SDK를 생성할 수 없습니다.

그래. 나는 HostOS로 FreeBSD에서 런타임을 재구축하기 위해 stage0 바이너리를 dogfodding하려고 시도하지 않았습니다.

ld: 오류: /root/runtime/artifacts/obj/coreclr/FreeBSD.x64.Release/src/dlls/dbgshim/dbgshim. 내보내기:1 : 알 수 없는 지시문: V1.0

이 문제를 별도로 보고할 가치가 있습니다. 문제를 수정하는 방법은 여러 가지가 있지만 이 패치가 어떤 차이를 만들까요?

--- a/eng/native/functions.cmake
+++ b/eng/native/functions.cmake
@@ -211,7 +211,7 @@ function(generate_exports_file)
   list(GET INPUT_LIST -1 outputFilename)
   list(REMOVE_AT INPUT_LIST -1)

-  if(CMAKE_SYSTEM_NAME STREQUAL Darwin)
+  if(CMAKE_SYSTEM_NAME STREQUAL Darwin OR CLR_CMAKE_HOST_FREEBSD)
     set(AWK_SCRIPT generateexportedsymbols.awk)
   else()
     set(AWK_SCRIPT generateversionscript.awk)
@@ -229,7 +229,7 @@ endfunction()

 function(generate_exports_file_prefix inputFilename outputFilename prefix)

-  if(CMAKE_SYSTEM_NAME STREQUAL Darwin)
+  if(CMAKE_SYSTEM_NAME STREQUAL Darwin OR CLR_CMAKE_HOST_FREEBSD)
     set(AWK_SCRIPT generateexportedsymbols.awk)
   else()
     set(AWK_SCRIPT generateversionscript.awk)

이 패치가 어떤 차이가 있습니까

저는 FreeBSD가 Darwin이 아니라 심볼 버전 스크립트가 진행되는 한 Linux를 따를 것으로 예상합니다. IMO 문제는 generateversionscript.awk에 GNU-awk에 특정한 것이 있다는 것일 가능성이 더 큽니다.

패치가 오류를 변경했습니다.
ld: error: /root/runtime/artifacts/obj/coreclr/FreeBSD.x64.Release/src/dlls/dbgshim/dbgshim.exports:1: unknown directive: _CreateProcessForLaunch
awk 버전 문제인 경우:

awk --version
awk version 20121220 (FreeBSD)

실험하기 쉬운 경우 gawk 패키지를 설치하고 CMake 파일의 호출을 gawk로 변경할 수 있습니까?

패치를 되돌렸습니다. gawk pkg를 설치했습니다.
build.sh 스크립트가 cmake args를 전달하는 방법을 알아내기에는 너무 게으르므로 즉시 의미가 없으므로 gawk->awk를 심볼릭 링크했습니다.
동일한 원래 오류
ld: error: /root/runtime/artifacts/obj/coreclr/FreeBSD.x64.Release/src/dlls/dbgshim/dbgshim.exports:1: unknown directive: V1.0

늦은 편집: Linux의 바이너리가 올바르게 빌드되지 않은 것 같습니다.

# ./dotnet --info
.NET SDK (reflecting any global.json):
 Version:   5.0.101-servicing.20605.0
 Commit:    c3a779b104

Runtime Environment:
 OS Name:     FreeBSD
 OS Version:  12
 OS Platform: FreeBSD
 RID:         osx-x64
 Base Path:   /root/runtime/.dotnet/sdk/5.0.100/

Host (useful for support):
  Version: 5.0.1
  Commit:  2ee13ec8e5

.NET SDKs installed:
  5.0.100 [/root/runtime/.dotnet/sdk]

.NET runtimes installed:
  Microsoft.NETCore.App 5.0.1 [/root/runtime/.dotnet/shared/Microsoft.NETCore.App]

To install additional .NET runtimes or SDKs:
  https://aka.ms/dotnet-download

주로 RID: osx-x64 가 몇 가지 문제를 일으킬 수 있습니다.

주로 RID: osx-x64 가 몇 가지 문제를 일으킬 수 있음

해당 RID는 지원되는 플랫폼과 지원되지 않는 플랫폼의 일부 해상도 후에 SDK에 의해 표시됩니다. 기본적으로 애플리케이션 실행에는 영향을 미치지 않습니다. 런타임에서 감지한 실제 RID가 정확하지 않으면 애플리케이션(예: dotnet(1) )이 제대로 실행되지 않습니다.
c# using System; using System.Runtime.InteropServices; class Program { static void Main() => Console.WriteLine("Real RID: {0}", RuntimeInformation.RuntimeIdentifier); }
내 상자에 Real RID: freebsd.12-x64 를 인쇄합니다.

ld 문제를 추적하기 위해 #45663을 열었습니다. 재현도 할 수 있었습니다.

@Thefrank ld 오류와 관련하여 다음을 시도하십시오.

diff --git a/eng/native/configurecompiler.cmake b/eng/native/configurecompiler.cmake
index 006a180fa0a..2a270572532 100644
--- a/eng/native/configurecompiler.cmake
+++ b/eng/native/configurecompiler.cmake
@@ -594,7 +594,7 @@ else (CLR_CMAKE_HOST_WIN32)
         ERROR_QUIET
         OUTPUT_VARIABLE ldVersionOutput)

-    if("${ldVersionOutput}" MATCHES "GNU ld" OR "${ldVersionOutput}" MATCHES "GNU gold")
+    if("${ldVersionOutput}" MATCHES "GNU ld" OR "${ldVersionOutput}" MATCHES "GNU gold" OR "${ldVersionOutput}" MATCHES "LLD")
         set(LD_GNU 1)
     elseif("${ldVersionOutput}" MATCHES "Solaris Link")
         set(LD_SOLARIS 1)

그러면 eng/native/functions.cmake 의 else 절이 여기에서 활성화됩니다.

function(set_exports_linker_option exports_filename)
    if(LD_GNU OR LD_SOLARIS)
        # Add linker exports file option
        if(LD_SOLARIS)
            set(EXPORTS_LINKER_OPTION -Wl,-M,${exports_filename} PARENT_SCOPE)
        else()
            set(EXPORTS_LINKER_OPTION -Wl,--version-script=${exports_filename} PARENT_SCOPE)
        endif()
    elseif(LD_OSX)
        # Add linker exports file option
        set(EXPORTS_LINKER_OPTION -Wl,-exported_symbols_list,${exports_filename} PARENT_SCOPE)
    endif()
endfunction()

솔직히 말해서, 저는 링커 전문가가 아니므로 이것이 작동하는 동안 FreeBSD의 clang에 실제로 필요한/정규화된 것이 무엇인지 자세히 살펴보지 않았습니다.

아, 링커 사용자 에이전트 문제가 다시 발생했습니다. LLD의 버전 문자열에는 구성 테스트의 GNU ld 경로를 따라 내려가려는 시도에 (compatible with GNU linkers) 되어 있지만 이 경우에는 분명히 영리하지 않습니다. :)

이제 LD_GNU 플래그의 이름이 다소 잘못되더라도 LLD에서 일치하는 것이 좋아 보입니다.

예, 더 많은 작업이 필요합니다. 플래그 이름은 이제 혼란스럽습니다. 아무도 이것을 그대로 커밋하려고하지 마십시오.

보낸 사람: 에드 마스트 알림 @github.com
보낸 날짜: 2020년 12월 7일 월요일 오전 10:26:48
받는 사람: dotnet /runtime
참조: Jason Pugsley [email protected] ; 멘션 @noreply.github.com
제목: Re: [dotnet/runtime] FreeBSD 지원(#14537)

아, 링커 사용자 에이전트 문제가 다시 발생했습니다. LLD의 버전 문자열은 구성 테스트의 GNU ld 경로를 따라 내려가기 위한 시도로 (GNU 링커와 호환 가능) 포함되지만 이 경우에는 분명히 영리하지 않습니다. :)

LD_GNU 플래그의 이름이 이제 다소 잘못되었더라도 LLD에서의 일치는 여기에서 좋아 보입니다.

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하거나 GitHub https://github.com/dotnet/runtime/issues/14537#issuecomment-739583816 에서 확인하거나 https://github.com/notifications/unsubscribe-auth/AECFDEXKTDFRAX4ZEE6VXZTSTQHLRANCNFSM4TS3XPPA 구독을 취소

https://github.com/dotnet/runtime/pull/45664 를 사용하기로 했습니다.
Clr은 Clr.Tools 하위 집합으로 빌드한 다음 실패합니다.

/root/runtime/.dotnet/sdk/5.0.100/Microsoft.Common.CurrentVersion.targets(4818,5): error MSB3030: Could not copy the file "/root/runtime/artifacts/bin/coreclr/FreeBSD.x64.Release/libjitinterface" because it was not found. [/root/runtime/src/coreclr/src/tools/aot/crossgen2/crossgen2.csproj]
/root/runtime/.dotnet/sdk/5.0.100/Microsoft.Common.CurrentVersion.targets(4818,5): error MSB3030: Could not copy the file "/root/runtime/artifacts/bin/coreclr/FreeBSD.x64.Release/libclrjit" because it was not found. [/root/runtime/src/coreclr/src/tools/aot/crossgen2/crossgen2.csproj]

하위 집합 "mono" 및 하위 집합 "libs"가 오류 없이 완료됨

@Thefrank 그것은 당신이 그 문제를 해결해야 하는 이 diff의 두 번째 부분입니다:

diff --git a/src/coreclr/src/tools/aot/crossgen2/crossgen2.csproj b/src/coreclr/src/tools/aot/crossgen2/crossgen2.csproj
index 2de5f568214..87242a728f0 100644
--- a/src/coreclr/src/tools/aot/crossgen2/crossgen2.csproj
+++ b/src/coreclr/src/tools/aot/crossgen2/crossgen2.csproj
@@ -12,7 +12,7 @@
     <OutputPath>$(BinDir)/crossgen2</OutputPath>
     <GenerateRuntimeConfigurationFiles>true</GenerateRuntimeConfigurationFiles>
     <EnableDefaultEmbeddedResourceItems>false</EnableDefaultEmbeddedResourceItems>
-    <RuntimeIdentifiers>linux-x64;linux-musl-x64;win-x64</RuntimeIdentifiers>
+    <RuntimeIdentifiers>linux-x64;linux-musl-x64;win-x64;freebsd-x64</RuntimeIdentifiers>
     <Configurations>Debug;Release;Checked</Configurations>
   </PropertyGroup>

@@ -53,6 +53,7 @@
     <LibraryNameExtension Condition="$([MSBuild]::IsOsPlatform('WINDOWS'))">.dll</LibraryNameExtension>
     <LibraryNameExtension Condition="$([MSBuild]::IsOsPlatform('LINUX'))">.so</LibraryNameExtension>
     <LibraryNameExtension Condition="$([MSBuild]::IsOsPlatform('OSX'))">.dylib</LibraryNameExtension>
+    <LibraryNameExtension Condition="$([MSBuild]::IsOsPlatform('FREEBSD'))">.so</LibraryNameExtension>

     <JitInterfaceLibraryName>$(LibraryNamePrefix)jitinterface$(LibraryNameExtension)</JitInterfaceLibraryName>
   </PropertyGroup>

조건에서 OR로 LINUX 라인에 추가하는 것이 더 나을 수 있습니다.

@jasonpugsley 가 트릭을 수행했습니다!
/root/runtime/src/coreclr/src/tools/aot/crossgen2/crossgen2.csproj : error NU1101: Unable to find package Microsoft.AspNetCore.App.Runtime.freebsd-x64. No packages exist with this id in source(s):
나는 내가 며칠 전에 무언가를 하는 것을 잊었다는 것을 알고 있었다! 이것은 흥미로울 것입니다

편집: crossgen 없이 (일명 후반부)

./build.sh -c Release -bl:buildlog.binlog

Build succeeded.
    0 Warning(s)
    0 Error(s)

Time Elapsed 00:12:05.56

이 게시물의 마지막 편집 편집 맹세:
테스트에 시간이 걸릴 수 있고 장기 실행 테스트라고 표시되지만 이것은 한 테스트에서 손을 뗄 수 없다는 것을 알고 있습니다.
System.Net.HttpListener.Tests: [Long Running Test] 'System.Net.Tests.HttpListenerResponseTests.AddLongHeader_DoesNotThrow', Elapsed: 00:36:20

2시간을 기다린 후 테스트를 종료했습니다. 다른 테스트는 여전히 실패했습니다.

/root/runtime/eng/testing/tests.targets(117,5): error : One or more tests failed while running tests from 'Microsoft.Extensions.Hosting.Unit.Tests'. Please check /root/runtime/artifacts/bin/Microsoft.Extensions.Hosting.Unit.Tests/net5.0-Release/testResults.xml for details! [/root/runtime/src/libraries/Microsoft.Extensions.Hosting/tests/UnitTests/Microsoft.Extensions.Hosting.Unit.Tests.csproj]
/root/runtime/eng/testing/tests.targets(117,5): error : One or more tests failed while running tests from 'System.Net.NameResolution.Functional.Tests'. Please check /root/runtime/artifacts/bin/System.Net.NameResolution.Functional.Tests/net5.0-Unix-Release/testResults.xml for details! [/root/runtime/src/libraries/System.Net.NameResolution/tests/FunctionalTests/System.Net.NameResolution.Functional.Tests.csproj]
/root/runtime/eng/testing/tests.targets(117,5): error : One or more tests failed while running tests from 'System.Net.NetworkInformation.Functional.Tests'. Please check /root/runtime/artifacts/bin/System.Net.NetworkInformation.Functional.Tests/net5.0-Release/testResults.xml for details! [/root/runtime/src/libraries/System.Net.NetworkInformation/tests/FunctionalTests/System.Net.NetworkInformation.Functional.Tests.csproj]
/root/runtime/eng/testing/tests.targets(117,5): error : One or more tests failed while running tests from 'Microsoft.VisualBasic.Core.Tests'. Please check /root/runtime/artifacts/bin/Microsoft.VisualBasic.Core.Tests/net5.0-Release/testResults.xml for details! [/root/runtime/src/libraries/Microsoft.VisualBasic.Core/tests/Microsoft.VisualBasic.Core.Tests.csproj]
/root/runtime/eng/testing/tests.targets(117,5): error : One or more tests failed while running tests from 'System.Console.Tests'. Please check /root/runtime/artifacts/bin/System.Console.Tests/net5.0-Release/testResults.xml for details! [/root/runtime/src/libraries/System.Console/tests/System.Console.Tests.csproj]
/root/runtime/eng/testing/tests.targets(117,5): error : One or more tests failed while running tests from 'System.Runtime.Extensions.Tests'. Please check /root/runtime/artifacts/bin/System.Runtime.Extensions.Tests/net5.0-Unix-Release/testResults.xml for details! [/root/runtime/src/libraries/System.Runtime.Extensions/tests/System.Runtime.Extensions.Tests.csproj]
/root/runtime/eng/testing/tests.targets(117,5): error : One or more tests failed while running tests from 'System.Net.Sockets.Tests'. Please check /root/runtime/artifacts/bin/System.Net.Sockets.Tests/net5.0-Unix-Release/testResults.xml for details! [/root/runtime/src/libraries/System.Net.Sockets/tests/FunctionalTests/System.Net.Sockets.Tests.csproj]
/root/runtime/eng/testing/tests.targets(117,5): error : One or more tests failed while running tests from 'System.IO.FileSystem.Tests'. Please check /root/runtime/artifacts/bin/System.IO.FileSystem.Tests/net5.0-Unix-Release/testResults.xml for details! [/root/runtime/src/libraries/System.IO.FileSystem/tests/System.IO.FileSystem.Tests.csproj]
/root/runtime/eng/testing/tests.targets(117,5): error : One or more tests failed while running tests from 'System.Net.Ping.Functional.Tests'. Please check /root/runtime/artifacts/bin/System.Net.Ping.Functional.Tests/net5.0-Unix-Release/testResults.xml for details! [/root/runtime/src/libraries/System.Net.Ping/tests/FunctionalTests/System.Net.Ping.Functional.Tests.csproj]
/root/runtime/eng/testing/tests.targets(117,5): error : One or more tests failed while running tests from 'System.Net.Requests.Tests'. [/root/runtime/src/libraries/System.Net.Requests/tests/System.Net.Requests.Tests.csproj]
/root/runtime/eng/testing/tests.targets(117,5): error : One or more tests failed while running tests from 'System.Net.WebSockets.Client.Tests'. [/root/runtime/src/libraries/System.Net.WebSockets.Client/tests/System.Net.WebSockets.Client.Tests.csproj]
/root/runtime/eng/testing/tests.targets(117,5): error : One or more tests failed while running tests from 'System.Security.Cryptography.X509Certificates.Tests'. Please check /root/runtime/artifacts/bin/System.Security.Cryptography.X509Certificates.Tests/net5.0-Unix-Release/testResults.xml for details! [/root/runtime/src/libraries/System.Security.Cryptography.X509Certificates/tests/System.Security.Cryptography.X509Certificates.Tests.csproj]
/root/runtime/eng/testing/tests.targets(117,5): error : One or more tests failed while running tests from 'System.Net.WebClient.Tests'. [/root/runtime/src/libraries/System.Net.WebClient/tests/System.Net.WebClient.Tests.csproj]
/root/runtime/eng/testing/tests.targets(117,5): error : One or more tests failed while running tests from 'System.Net.Security.Tests'. Please check /root/runtime/artifacts/bin/System.Net.Security.Tests/net5.0-Unix-Release/testResults.xml for details! [/root/runtime/src/libraries/System.Net.Security/tests/FunctionalTests/System.Net.Security.Tests.csproj]
/root/runtime/eng/testing/tests.targets(117,5): error : One or more tests failed while running tests from 'System.Diagnostics.Process.Tests'. Please check /root/runtime/artifacts/bin/System.Diagnostics.Process.Tests/net5.0-Unix-Release/testResults.xml for details! [/root/runtime/src/libraries/System.Diagnostics.Process/tests/System.Diagnostics.Process.Tests.csproj]
/root/runtime/eng/testing/tests.targets(117,5): error : One or more tests failed while running tests from 'System.Security.Cryptography.Xml.Tests'. [/root/runtime/src/libraries/System.Security.Cryptography.Xml/tests/System.Security.Cryptography.Xml.Tests.csproj]
/root/runtime/eng/testing/tests.targets(117,5): error : One or more tests failed while running tests from 'System.Runtime.Tests'. Please check /root/runtime/artifacts/bin/System.Runtime.Tests/net5.0-Unix-Release/testResults.xml for details! [/root/runtime/src/libraries/System.Runtime/tests/System.Runtime.Tests.csproj]
/root/runtime/eng/testing/tests.targets(117,5): error : One or more tests failed while running tests from 'System.Net.HttpListener.Tests'. [/root/runtime/src/libraries/System.Net.HttpListener/tests/System.Net.HttpListener.Tests.csproj]
    0 Warning(s)
    18 Error(s)

Time Elapsed 02:11:29.07
Build failed (exit code '1').