Runtime: Dukungan untuk FreeBSD

Tampaknya ada kesepakatan sejauh menyangkut https://github.com/dotnet/corefx/issues/1576 .

Ketika kami juga memiliki keputusan tentang https://github.com/dotnet/corefx/issues/1625 kami harus dapat mulai mengirimkan beberapa kode.

Kesepakatan tentang dotnet/runtime#14536 telah dicapai oleh portteam, kecuali MSFT memilih sebaliknya, itu akan menjadi FreeBSD . Masalah dotnet/corefx#1999 berpotensi menjadi masalah yang memperkenalkan definisi ke dalam API publik.

Kesepakatan tentang dotnet/runtime#14536 telah dicapai oleh portteam, kecuali MSFT memilih sebaliknya maka FreeBSD

Jika saya membacanya dengan benar, ini berarti bahwa ketika https://github.com/dotnet/corefx/pull/1999 digabungkan, kami dapat mempertimbangkan MSFT ini menyetujui API publik baru, dan oleh karena itu dapat melanjutkan masalah yang tersisa dengan permintaan tarik biasa tanpa perlu persetujuan MSFT.

Jika demikian, itu terdengar bagus bagi saya.

Langkah selanjutnya sesuai https://github.com/dotnet/corefx/pull/1999#issuecomment -111279577 adalah:

1. "Tim port FreeBSD" melanjutkan pekerjaan mereka untuk mendapatkan versi FreeBSD dari CoreFX yang diproduksi (dilacak oleh dotnet/corefx#1626).
2. Tim port menampilkan cukup banyak tumpukan CoreFX dan CoreCLR di FreeBSD sehingga kami dapat mulai menjalankan pengujian unit CoreFX di FreeBSD.
3. Tes mencapai beberapa tingkat kualitas minimal. Saya belum tahu persis seperti apa ini, tetapi saya berharap itu berarti sesuatu seperti sebagian besar tes lulus. Idealnya kami tidak akan menonaktifkan banyak tes khusus hanya untuk FreeBSD (dibandingkan dengan Linux dan OSX, kami tidak ingin menggunakan FreeBSD dengan standar yang lebih tinggi daripada platform *NIX lain yang kami miliki di sana).
4. Bekerja dengan tim port FreeBSD, tim CoreFX mendapatkan tes CoreFX yang ditambahkan ke sistem CI kami yang berjalan di FreeBSD.
5. Diskusikan penggabungan PR berdasarkan masalah dotnet/runtime#14536, yang menambahkan properti.

Kedengarannya seperti rencana yang sepenuhnya masuk akal bagi saya.

Oke, mari kita mulai bekerja untuk membuat corefx berfungsi.

Kendala pertama dalam membangun corefx di FreeBSD tampaknya mono. Skrip build menegaskan bahwa versi 4.1 diperlukan. @ajensenwaud melakukan beberapa pekerjaan pada ini di Frankfurt-Host, tapi saya tidak yakin seberapa lengkapnya.

Saya akan mengantri build untuk saat ini dan melihat seperti apa hasilnya.

Sunting: Build (mono) mogok dengan kicker berikut di akhir:

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.

Kendala pertama dalam membangun corefx di FreeBSD tampaknya mono

FWIW, menurut saya pribadi ini bukan kendala pertama. Ada dua masalah terkait build:

1. Membangun rakitan yang berfungsi dengan benar di FreeBSD
2. Membangun rakitan itu di FreeBSD

(1) sangat penting, dan apakah saya percaya apa yang dimaksud dengan masalah ini. (2) sangat bagus untuk dimiliki, tetapi kekurangannya tidak menghalangi pembuatan sistem yang bagus untuk menjalankan kode terkelola di FreeBSD.

Anda tentu saja bebas untuk memprioritaskan apa pun yang Anda inginkan, tetapi rekomendasi saya adalah untuk fokus pada (1) daripada (2).

Perhatikan bahwa kami masih memiliki masalah dalam membangun corefx di Linux dan membangunnya di OSX, sehingga sistem CI kami membangun rakitan untuk platform tersebut di Windows; kemudian mengirimkan rakitan yang dihasilkan ke platform target untuk menjalankan tes.

Itu cukup adil. Saya hanya berasumsi bahwa akan lebih mudah untuk mendapatkan dukungan platform FreeBSD umum yang dimasukkan ke dalam corefx jika kita benar-benar dapat membangunnya sendiri di FreeBSD.

Saya akan puas dengan bangunan yang diprakarsai Windows untuk saat ini dan mencoba untuk menyatukan konfigurasi build.

@josteink btw. corefx sekarang harus dibangun di atas Mono 4.0.1.44.

@akoeplinger Bagus. Itu membuat saya berharap kami bisa menjalankannya di FreeBSD juga :)

Poin bagus. Namun jika kita benar-benar ingin corefx menjadi bagian dari lingkungan FreeBSD, kita benar-benar membutuhkannya untuk dapat dikompilasi dari sumber untuk memasukkannya ke dalam sistem Port.

Saya memang mendengar bahwa Mono 4.0.1.44 memperbaiki banyak masalah ini tetapi belum sempat memainkannya. Saya tahu tim port sedang memperbarui port Makefile serta kami berbicara dengan tambalan baru.

Pada 12 Juni 2015, pukul 20:21, Stephen Toub [email protected] menulis:

Kendala pertama dalam membangun corefx di FreeBSD tampaknya mono

FWIW, menurut saya pribadi ini bukan kendala pertama. Ada dua masalah terkait build:

Membangun rakitan yang berfungsi dengan benar di FreeBSD
Membangun rakitan itu di FreeBSD
(1) sangat penting, dan apakah saya percaya apa yang dimaksud dengan masalah ini. (2) sangat bagus untuk dimiliki, tetapi kekurangannya tidak menghalangi pembuatan sistem yang bagus untuk menjalankan kode terkelola di FreeBSD.

Anda tentu saja bebas untuk memprioritaskan apa pun yang Anda inginkan, tetapi rekomendasi saya adalah untuk fokus pada (1) daripada (2).

Perhatikan bahwa kami hampir tidak memiliki corefx build-on-Linux dan build-on-OSX, sehingga sistem CI kami membangun rakitan untuk platform tersebut di Windows; kemudian mengirimkan rakitan yang dihasilkan ke platform target untuk menjalankan tes.

—
Balas email ini secara langsung atau lihat di GitHub.

Ya, saya sama sekali tidak setuju... mampu _build_ corefx di Linux, OSX, dan FreeBSD itu penting. Saya hanya menyarankan bahwa dari perspektif prioritas lebih penting untuk dapat benar-benar _run_ corefx di Linux, OSX, dan FreeBSD. :wink: Jika keduanya dapat dikerjakan secara paralel, itu lebih baik.

@ghuntley ,
akan menjadi super :keren: jika kita memiliki daftar tugas penurunan harga yang menguraikan apa yang tersisa:

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

diterjemahkan sebagai:

• [ ] tugas 1
• [ ] tugas 2
• [ ] tugas 3

Ini mungkin akan mendorong orang lain untuk mencetak prestasi tersebut dan dukungan FreeBSD akan mendarat lebih cepat dari yang diperkirakan! :kacamata hitam:

Sepengetahuan saya, pekerjaan berikut di CoreFX diperlukan untuk dukungan FreeBSD:

• [x] Memperkenalkan platform FreeBSD ke alat dan skrip build. (Dikerjakan oleh @josteink dan saya, PR dotnet/corefx#2021 digabung, dotnet/corefx#2030 digabung)

13 Assembly tidak dapat dikompilasi sendiri dan membutuhkan perubahan khusus FreeBSD. Sebagian besar potongan Interop yang sudah ada untuk Linux/OS X (urutkan berdasarkan kemunculan di output build):

• [x] System.Private.URI (selesai, PR dotnet/corefx#2032 digabungkan)
• [x] System.Console (selesai, PR dotnet/corefx#2031 digabungkan)
• [x] System.Diagnostics.Debug (selesai, PR dotnet/corefx#2039 digabungkan)
• [x] System.Diagnostics.Process (diskusi dotnet/corefx#2070, PR dotnet/corefx#3257)
• [x] System.IO.Compression.ZipFile (selesai, PR dotnet/corefx#2041 digabungkan)
• [x] System.IO.FileSystem.DriveInfo (diskusi dotnet/corefx#2526, PR dotnet/corefx#2606)
• [x] System.IO.FileSystem.Watcher (diskusi dotnet/corefx#2046, PR dotnet/corefx#3257)
• [x] System.IO.FileSystem (selesai, PR dotnet/corefx#2049 digabungkan)
• [x] System.IO.MemoryMappedFiles (diskusi dotnet/corefx#2527, PR dotnet/corefx#3143)
• [x] System.IO.Pipes (diskusi dotnet/corefx#2528, PR dotnet/corefx#2974)
• [x] System.Net.NameResolution (diskusi dotnet/corefx#2988, PR dotnet/corefx#3471)
• [x] System.Security.Cryptography.Hashing.Algorithms (selesai, PR dotnet/corefx#2040 digabungkan)
• [x] System.Security.SecureString (selesai, PR dotnet/corefx#2039 digabungkan)
• [x] System.Runtime.Environment (diblokir oleh dotnet/corefx#1999 )
• [x] System.Runtime.InteropServices.RuntimInformation (selesai, PR dotnet/corefx#2068 digabungkan)

Saya akan mencoba memperbarui daftar itu berdasarkan PR yang dibuka dan digabungkan.

FYI: PR dotnet/corefx#2039 digabungkan

Hanya mencoba untuk menjadi yang terdepan di sini... Bagaimana rencana kita untuk mengimplementasikan System.IO.FileSystem.Watcher ?

Iirc FreeBSD tidak memiliki inotify seperti Linux dan Windows (itu juga mengapa tidak ada Dropbox terakhir kali saya memeriksanya). Apakah ini akan menjadi sumber masalah potensial yang akan datang kepada kita? Atau ada yang punya ide bagaimana cara menyiasatinya?

Saya sarankan kita mematikannya untuk saat ini dan melemparkan PlatformNotSupportedException seperti yang disarankan Stephen Toub dalam topik lain (https://github.com/dotnet/corefx/pull/2021#issuecomment-111602342). Kemudian kami memiliki setidaknya satu set lengkap dan kami dapat terus bekerja pada masalah tertentu tanpa menghalangi langkah lebih lanjut.

Maukah Anda membuka edisi terpisah untuk itu?

Mari pindahkan diskusi System.IO.FileSystem.Watcher ke dotnet/corefx#2046

Teman-teman apakah ada pemblokir seperti itu untuk System.Diagnostics.Process ?

@jasonwilliams200OK menambahkan FreeBSD ke S.RT.I.RI pagi ini yang digabungkan tetapi tes FreeBSD dalam CheckPlatformTests harus dicadangkan hingga dotnet/buildtools diperbarui.

• [ ] Perbarui alat pembuatan untuk mendukung FreeBSD - https://github.com/dotnet/buildtools/pull/180
• [ ] Terapkan kembali tes [Fact,PlatformSpecific(PlatformID.FreeBSD)] ke CheckPlatformTests - lihat https://github.com/dotnet/corefx/pull/2068#discussion_r32570244 dan https://github.com/dotnet/corefx/pull/2068#discussion_r32570244
• [ ] Tambahkan public static OSPlatform FreeBSD ke https://github.com/dotnet/corefx/pull/2068

@jasonwilliams200OK ada beberapa diskusi tadi malam tentang System.Diagnostics.Process di gitter yang telah diformalkan menjadi https://github.com/dotnet/corefx/issues/2070

@ghuntley , terima kasih. Saya benar-benar membaca pesan-pesan itu. System.Diagnostics.Process adalah salah satu yang rumit. AFAIK, tim io.js memiliki tantangan serupa dengan manajemen proses FreeBSD. Tim Mono mungkin telah berhasil, jadi mari berharap jika @akoeplinger and co. bisa mencerahkan kita tentang hal ini? :)

System.IO.FileSystem.DriveInfo

Seperti yang dibahas di gitter, Untuk yang ini saya mencoba melihat penggunaan dasar 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);
  }
}

Menjalankan sampel itu menghasilkan output ini:

$ ./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
$

Jadi sepertinya itu melakukan apa yang kita butuhkan. Pertanyaannya adalah, haruskah kita melakukan penyaringan apa pun pada hasilnya?

Melihat "maksud" dari objek DriveInfo , yang berasal dari dunia Windows .NET, sering kali untuk menghitung lokasi yang tersedia untuk menyimpan atau mengambil file ( C: , D: , dll). Tetapi ketika menggunakan sistem file hierarki Unix, mengembalikan / akan cukup untuk memenuhi kebutuhan tersebut.

Jadi apa yang harus kita kembalikan? Apa yang akan berguna? Bahkan harus mempertimbangkan itu berguna atau tidak?

Versi Linux hanya membuang semuanya, kecuali hal-hal yang diatur untuk diabaikan:

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

Saya mencoba memasukkan filter berikut, tetapi tidak benar-benar mengubah apa pun dalam hal output:

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

Ada pendapat?

@josteink , penggalian yang bagus! Berdasarkan https://github.com/dotnet/corefx/issues/815#issuecomment -113825960 dan https://github.com/dotnet/corefx/issues/1729 , saya pikir kita harus berkolaborasi dengan @sokket untuk menghasilkan solusi dengan karya di berbagai Unis.

Saya memiliki versi yang berjalan di OSX yang menggunakan getmntinfo dan statfs untuk mendapatkan informasi tentang setiap titik pemasangan, yang sepertinya merupakan pemetaan paling logis dari konsep Drive Windows. Saya akan memeriksa ulang apakah definisi fungsi dan struct pada OSX cocok dengan definisi FreeBSD dan, jika demikian, komit saya untuk OSX juga akan berfungsi untuk BSD.

Saya pasti akan menambahkan Anda ke PR saya @josteink

Kedengarannya bagus. Terima kasih atas perhatiannya dan terima kasih juga telah memberi FreeBSD beberapa cinta.

Saya melihat ke beberapa pinvoke dasar untuk fungsi-fungsi ini, dan sepertinya kita perlu melakukan semua pengaturan dan konversi sendiri, jadi jika ada orang lain yang telah berusaha, siapa saya untuk mengatakan tidak? ;)

Tidak masalah...sepertinya perbedaan utama adalah dengan deklarasi struct; karena kita mungkin akan mencapai ini lebih banyak di masa depan, saya melakukan beberapa refactoring yang akan memungkinkan kita untuk berbagi banyak tanda tangan PINvoke. Saya akan menambahkan deskripsi yang lebih besar di PR saya (hari ini atau besok, berdasarkan cara pengujian berjalan) tetapi pada dasarnya saya menambahkan tanda tangan PInvoke dan tanda tangan struct untuk FreeBSD (berdasarkan header yang saya temukan online) dan dikompilasi. Saya telah mengujinya di Mac sehingga _should_ (secara teori...) bekerja di FreeBSD karena ini hanya perubahan deklarasi struct, tetapi jarak tempuh Anda mungkin berbeda :). Jika tidak, Anda akan memiliki kelas DriveInfo dan PInvokes 99% dari perjalanan ke sana dan hanya akan memerlukan beberapa penyesuaian berdasarkan nuansa FreeBSD.

Berita bagus @sokket. Saya telah membuatkan Anda akun di mesin yang digunakan tim port untuk pengembangan, berbasis Eropa tetapi selalu aktif dan memiliki banyak memori dan kekuatan pemrosesan. Semoga ini akan membantu dan menghilangkan beberapa gesekan saat bekerja dengan FreeBSD.

# ssh [email protected]

Otentikasi kata sandi dinonaktifkan, gunakan salah satu kunci Anda .

@josteink lihat juga masalah: https://github.com/dotnet/corefx/issues/815 (System.IO.FileSystem.DriveInfo untuk Mac/FreeBSD)

Apakah ada pembaruan? Apakah ada yang mengimplementasikan sisa rakitan di FreeBSD?

Saya sibuk mengurus bayi baru saya, tidak punya waktu untuk coding di mana pun.

Saya menduga bahwa masalah seperti ini telah terbengkalai dan saya kira ini menegaskannya sampai batas tertentu.

Untuk majelis yang masih belum diimplementasikan, saya menautkan masalah "bagaimana menerapkan" dalam daftar di atas. Saya harap itu membantu mengoordinasikan upaya untuk mengimplementasikan majelis yang tersisa ini.

Saya harus mengakui bahwa saya mengalami kesulitan melacak apa yang telah kami lakukan dan di mana, jadi itu jelas merupakan langkah yang baik. Kerja yang baik :)

Di mana saya menemukan itu? Akan sangat menyenangkan untuk mendapatkan rakitan yang tersisa
dilaksanakan.

Pada 25/07/15 22:10, Jan Henke menulis:

Untuk majelis yang masih belum dilaksanakan, saya menautkan "bagaimana
untuk mengimplementasikan"-masalah dalam daftar di atas. Saya harap itu membantu koordinasi
upaya untuk mendapatkan majelis yang tersisa ini dilaksanakan.

—
Balas email ini secara langsung atau lihat di GitHub
https://github.com/dotnet/corefx/issues/1626#issuecomment -124838781.

Komentar ini di sini: https://github.com/dotnet/corefx/issues/1626#issuecomment -111800540

Saya sekarang menunggu shim asli selesai, karena ini akan mengambil alih sebagian besar pekerjaan untuk membuat rakitan ini bekerja di FreeBSD.

@nguerrera akan sangat bagus jika Anda dapat memberi tahu kami tentang perkembangannya. :)

Memperbarui:
@janhenke mengkonfirmasi bahwa dengan https://github.com/dotnet/corefx/pull/2974 digabungkan, System.IO.Pipes dibangun di FreeBSD! :kacamata hitam:

Memperbarui:
dotnet/corefx#2527 ditutup, System.IO.MemoryMappedFiles dibangun di FreeBSD.
Terima kasih @janhenke atas konfirmasinya!

Berkat pendekatan shims, itu hanya turun untuk memastikan shims dikompilasi di FreeBSD. Syukurlah itu membuat hidup jauh lebih mudah. :)

dotnet/corefx#3257 akan membawa kita berdua System.Diagnostic.Process dan System.IO.FileSystem.Watcher meninggalkan hanya System.Net.NameResolution belum terselesaikan. (Saya akan memeriksa dua majelis yang disebutkan setelah PR digabungkan dan berfungsi di FreeBSD)

dotnet/corefx#3471 akan membawa kita System.Net.NameResolution dan melengkapi daftar di atas.

dotnet/corefx#3471 baru saja digabungkan :)

@sokket , terima kasih atas pembaruannya. Saya membangun master (f467911) di FreeBSD menggunakan panduan ini: https://Gist.github.com/jasonwilliams200OK/6efa7907e66275df2d24. Pemblokir saat ini adalah https://github.com/dotnet/buildtools/issues/292, yang diperbaiki di hulu tetapi menunggu peluncuran buildtools berikutnya. :)

Pembaruan: buildtools baru dengan perbaikan untuk dotnet/buildtools#292 telah mendarat di master CoreFX. Penghenti berikutnya dari buildtools adalah https://github.com/dotnet/buildtools/issues/300 : tidak ada alat khusus OS untuk dapat menjalankan tes.

@janhenke , Anda telah menandai System.Diagnostics.Process (#2070) dan System.IO.FileSystem.Watcher (#2046) sebagai selesai; tetapi tidak diimplementasikan atau dikompilasi di FreeBSD. Sudahkah Anda benar-benar memverifikasi daftar dengan menyusun kode terkelola?

Berdasarkan pengalaman saya baru-baru ini dengan komit 60c78da3c918b0d256cc1f878de06d351dbe3342 (lihat msbuild.log ), rakitan berikut tidak dapat dikompilasi:

• Sistem.Diagnostik.Proses
• System.Diagnostics.ProcessManager
• System.Diagnostics.ThreadInfo
• System.IO.FileSystemWatcher
• System.Net.SocketAddress _(baiklah, yang ini baru saja ditambahkan)_

Sejauh yang saya ingat, saya memverifikasi kompilasi shims terkait. Karena kode yang dikelola harus bebas dari kode khusus FreeBSD. Shim yang Anda sebutkan seharusnya dihilangkan dengan PR yang ditautkan di atas.
Tetapi saya juga menjalankan kompilasi penuh di antaranya. Setidaknya System.Diagnostics.ThreadInfo dan System.IO.FileSystemWatcher melakukan kompilasi. Jadi pasti ada yang mundur.

Shim yang Anda sebutkan seharusnya dihilangkan dengan PR yang ditautkan di atas.

Sebenarnya, PR https://github.com/dotnet/corefx/pull/3257 tidak terkait dengan shim. Masih ada beberapa kode PAL dalam proyek yang dikelola (pendekatan lama), oleh karena itu diperlukan untuk membangun rakitan yang dikelola untuk benar-benar yakin.

Sebenarnya, PR dotnet/corefx#3257 tidak terkait dengan shim.

saya tidak setuju. Ini adalah refactoring kode P/Invoke ke shim System.Native. Juga seperti yang saya edit di atas, saya mengingat setidaknya beberapa rakitan yang dikompilasi di antaranya.

saya tidak setuju

https://github.com/dotnet/corefx/pull/3257/files : lihat contoh .Unix.cs dan .Linux.cs untuk System.Diagnostics. . Perhatikan bahwa .OSX.cs tidak tersentuh.

Ini adalah refactoring kode P/Invoke ke System.Native shim

Ya itu memperbaiki beberapa pembantu umum di bawah System.Native , tetapi tidak System.Diagnostics.* et al.

Bahkan ketika rakitan ini hanya P/Memanggil ke System.* lib, mungkin masih ada pekerjaan FreeBSD yang diperlukan untuk beberapa di antaranya, misalnya System.Diagnostics.Process dan System.IO.FileSystem.Watcher. Mereka menggunakan fungsionalitas khusus untuk Linux dan OS X, dan kami tidak berencana untuk mencoba mengabstraksikannya di balik shim asli. Tujuan dari shims tidak berakhir dengan biner terkelola tunggal untuk Unix, meskipun itu adalah properti yang sangat bagus ketika berasal dari pekerjaan; tujuan utamanya adalah untuk menghindari perbedaan ABI yang menyebabkan kerapuhan. Saya berharap setidaknya beberapa rakitan akan terus memiliki binari khusus Linux/OS X, di mana biner FreeBSD juga akan dibutuhkan.

FYI, tidak ada rakitan corefx bernama System.Diagnostics.ProcessManager,
Sistem.Diagnostik.ThreadInfo,
System.IO.FileSystemWatcher, atau
System.Net.SocketAddress. Itu adalah tipe di majelis lain.

Saya berharap setidaknya beberapa rakitan akan terus memiliki binari khusus Linux/OS X, di mana biner FreeBSD juga akan dibutuhkan.

Apakah itu berarti kapan pun Solaris dan non-glibc (musl dan libc) yang menargetkan Linux seperti dukungan Alpine akan tiba, mereka akan memiliki binari terpisah? Dan kemudian arsitektur yang berbeda ARM, MIPS, RISC, SPARC dll akan memerlukan tingkat pemisahan yang lain?

Bukankah masuk akal untuk menyatukannya ke antarmuka POSIX / sys-calls sebanyak mungkin dan fitur-mendeteksi perbedaan menggunakan konfigurasi (melalui CMake) untuk digunakan dalam biner yang sama (kecuali jika itu memengaruhi ukuran/kinerja perakitan secara signifikan)? Seperti yang saya pahami, biner System.Native.so memiliki pembantu umum untuk System.*.Native.so spesifik lainnya yang tampaknya cukup untuk kepatuhan prinsip pemisahan masalah. Tetapi jika diubah menjadi System.Net.Http.FreeBSD.ARM.Native.so atau System.Net.Http.Solaris.SPARC.so , maka itu akan sangat tidak dapat diatur dengan "terlalu banyak bagian yang bergerak" dll.

tidak ada rakitan corefx bernama

Poin bagus. Saya sebenarnya melihat contoh kegagalan dalam log msbuild dan jumlah file .OSX.cs dan .Linux.cs . :senyum:

Bukankah masuk akal untuk menyatukannya ke antarmuka POSIX/panggilan sys sebanyak mungkin

Kami melakukannya. Bagaimana Anda mengusulkan melakukan menonton file dengan baik melalui POSIX? Bagaimana Anda mengusulkan kami melakukan pencacahan proses dengan baik melalui POSIX?

Tetapi jika diubah menjadi System.Net.Http.FreeBSD.ARM.Native.so atau System.Net.Http.Solaris.SPARC.so, maka itu akan sangat tidak dapat diatur dengan "terlalu banyak bagian yang bergerak" dll

Saya tidak mengerti ini. Inti dari file .so asli adalah Anda mendapatkan binari asli yang berbeda untuk setiap platform target, tetapi mereka tidak diberi nama System.Whatever.Platform.ext, hanya System.Whatever.ext; yang memungkinkan kompiler untuk mengambil logika umum yang sama dan menggunakannya dengan definisi khusus untuk platform itu. Ini hanya berfungsi ketika simbol yang sama ada di setiap platform; kompiler tidak secara ajaib mengambil kode yang ditulis untuk menggunakan inotify dan mengizinkannya bekerja dengan antarmuka menonton file dari beberapa sistem lain. Secara umum kami telah berusaha keras untuk menggunakan API standar yang masuk akal, tetapi untuk tempat di mana API tersebut tidak ada atau tidak terstandarisasi dengan baik atau di mana terdapat solusi khusus platform yang lebih baik, kami telah menggunakan platform yang lebih baik- solusi spesifik, misalnya menggunakan procfs untuk enumerasi proses di Linux, menggunakan inotify untuk menonton sistem file di Linux, dll. Apakah logika khusus platform tersebut hidup dalam kode terkelola atau asli tidak terlalu penting dari kemudahan porting-ke- perspektif platform tambahan, seperti ketika platform baru itu muncul, jika API yang ada berfungsi, maka solusi yang ada juga berfungsi, dan jika tidak, Anda perlu menulis solusi baru untuk platform tersebut. Jadi kami telah mencoba melakukan sebanyak mungkin dalam kode terkelola, menggunakan asli hanya untuk shim 1:1 yang membuat kode terkelola itu jauh lebih portabel di mana API target portabel. Kami telah menggunakan #ifdefs dalam kode asli untuk menutupi detail kecil, di mana API ini pada platform apa yang cukup dekat dengan API itu pada platform lain, tetapi itu tidak mencakup seluruh solusi yang benar-benar berbeda; pada saat itu abstraksi menjadi API terkelola dan kami melakukan implementasi terkelola yang berbeda untuk setiap sistem.

Jika FreeBSD mengekspos inotify seperti yang dilakukan Linux atau jika mengekspos EventStream seperti yang dilakukan OS X, maka ketika API OS tersebut berada di belakang shim, shim dapat dengan mudah dibuat untuk bekerja dengan FreeBSD, dan biner terkelola yang sama dapat digunakan di FreeBSD. Jika FreeBSD tidak mengekspos API tersebut, maka Anda harus menulis implementasi kustom System.IO.FileSystem.Watcher dengan beberapa solusi menonton file yang tersedia di FreeBSD. Komentar serupa untuk System.Diagnostics.Process. Apakah kode untuk menonton file ada di shim atau tidak, berdampak kecil pada hal itu.

Rencananya adalah semua API asli tersebut pada akhirnya akan dipindahkan ke belakang shim. Tetapi mereka jauh dari prioritas, karena tidak terlalu portabel, dan Anda telah melihat kami memulai dengan API dari libc yang (atau seharusnya) diekspos di mana-mana.

Bagaimana Anda mengusulkan melakukan menonton file dengan baik melalui POSIX?

Kami tidak dapat melakukan semuanya POSIX, karena inotify khusus untuk Linux. FreeBSD/OSX menawarkan implementasi terpisah.

Usul:

Dari sudut pandang distribusi binari asli, setiap OS harus menerima kumpulan binari yang sama dengan nama yang sama, tetapi fungsionalitasnya berbeda.

Berikut adalah struktur yang diusulkan:

# 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

Ini pada dasarnya adalah apa yang kita miliki, misalnya

• "common_function_for_posix_compliants" adalah fungsi 1: 1 yang di-shimmed asli yang dikonsumsi dari logika dalam biner terkelola Unix bersama
• "slightly_diverged_function" adalah fungsi native-shimmed hampir 1: 1 dengan beberapa #ifdefs asli yang dikonsumsi dari logika dalam biner terkelola Unix bersama
• "painfully_diverged_watch_function" adalah / akan di-shimmed secara native fungsi 1:1 yang dikonsumsi dari logika dalam binari terkelola khusus platform

Perbedaan sebenarnya adalah apakah kode yang mengimplementasikan logika "menyakitkan divergen" dilakukan dalam C# atau C++, dan kami telah memilih C# dan semuanya sudah diimplementasikan dalam C#. Saya belum melihat argumen yang meyakinkan mengapa dalam kasus seperti itu menulis ulang semuanya dalam C++ akan menjadi opsi yang jauh lebih menarik.

@ jasonwilliams200OK Dengan pembaruan hari ini ke mono saya membangun corefx di FreeBSD sendiri lagi. Ada banyak pesan kesalahan baru sejak terakhir kali saya membangunnya.
Saya bertanya-tanya apakah Interop.Libc akan hilang pada akhirnya?

@stephentoub Semuanya bermuara pada pengemasan. Memiliki semua kode khusus platform di bagian asli memiliki manfaat memiliki satu perakitan terkelola untuk semua platform mirip Unix.
Selain itu, saya sangat berpikir kita membutuhkan implementasi umum untuk "kode terkelola yang bergantung pada platform ini. Bahkan jika itu hanya melempar NotImplementedExcpetion. Dengan cara itu Anda dapat lebih mudah melakukan port ke platform baru, jika setidaknya mengkompilasi semuanya segera. Juga akan memberikan kesempatan untuk setidaknya mencoba berjalan di platform yang tidak didukung.
Umumnya jauh lebih mudah jika Anda setidaknya dapat segera mengkompilasi dengan sukses.

@stephentoub , maaf saya mencampur C++ dengan C#. Sekarang saya mengerti bahwa lapisan asli hanya mengekspos titik masuk tersebut (fungsi libs asli atau syscalls) dan membersihkan IO dan kode terkelola adalah tempat kami memutuskan metode utilitas terbungkus khusus platform / syscall terbungkus yang akan dikonsumsi. Selain itu, kedua tingkatan (asli dan terkelola) tidak dapat menjadi OS-agnostik di mana fungsionalitas non-POSIX akan dikonsumsi.

@janhenke , saya setuju. Saya juga membangun master saat kita berbicara. Ada masalah penandatanganan Majelis berulang lainnya, saya memukul:

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]

akan segera memposting tautan inti msbuild.log lengkap.

Selain itu, saya sangat berpikir kita memerlukan implementasi umum untuk "kode terkelola yang bergantung pada platform" ini.

Saya setuju. Alih-alih kelas parsial, kita mungkin dapat menggunakan pewarisan dengan metode virtual umum dan sebagian besar umum di kelas dasar abstrak dan menimpa "kebanyakan umum / sebagian berbeda" jika perlu. Kemudian terapkan metode abstrak yang sama sekali berbeda untuk setiap OS. Dengan pendekatan IMO ini, jika di mana spesialisasi/generalisasi kehilangan KERING, kita dapat mempekerjakan keturunan pewarisan multi-derajat. Tetapi terakhir kali saya memeriksa, kelas parsial lebih disukai daripada asosiasi orang tua-anak di CoreFX (untuk beberapa alasan saya tidak ingat). :)

Ini adalah msbuild.log untuk komit 2d36889:

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

/cc: @akoeplinger

@ jasonwilliams200OK Mengapa begitu rumit. Yang dibutuhkan hanyalah kondisi "jika bukan Windows,Linux,OS X" dalam file proyek. Jadi, sertakan kumpulan file khusus platform dalam build atau yang generik.

Saya tidak berpikir fakta bahwa beberapa rakitan tidak dapat membangun/berfungsi untuk FreeBSD namun harus menjadi penghalang utama untuk menguji sisanya. Kita mungkin harus membuatnya sehingga pekerjaan yang tertunda (FileSystemWatcher, Process, Networking) dilewati dalam build dan uji coba di FreeBSD. Kemudian kita dapat memunculkannya secara individual sambil memiliki proses untuk mencegah regresi pada apa yang sudah berhasil.

Saya tidak berpikir fakta bahwa beberapa rakitan tidak dapat membangun/berfungsi untuk FreeBSD namun harus menjadi penghalang utama untuk menguji sisanya

Sepakat

Kita mungkin harus membuatnya sehingga pekerjaan yang tertunda (FileSystemWatcher, Proses, Jaringan) dilewati dalam pembuatan dan uji coba di FreeBSD

Atau mirip dengan apa yang disarankan @janhenke , izinkan saja mereka untuk membangun, baik dengan mematikan file yang membuang PlatformNotSupported, atau hanya dengan memetakan FreeBSD ke salah satu kasus yang berfungsi, misalnya jika FreeBSD dipilih, buat saja yang Linux ( itu tidak akan berfungsi, tetapi itu akan membangun).

Dengan @ellismg perubahan terbaru (#3684), saya dapat menjalankan tes dengan menyederhanakan metode sebelumnya (https://github.com/dotnet/coreclr/issues/1633#issuecomment-143669303):

• Setelah https://Gist.github.com/jasonwilliams200OK/6efa7907e66275df2d24 (terutama langkah untuk membangun shim asli secara terpisah _after_ keluar build.sh dengan status 1), unduh artefak CoreCLR zip: cd /root; curl -o bins.zip "http://dotnet-ci.cloudapp.net/job/dotnet_coreclr/job/debug_freebsd/lastSuccessfulBuild/artifact/*zip*/archive.zip (jangan lupa kutipan di sekitar URL) dan kemudian unzip bins.zip; chmod -R 0777 archive/; rm bins.zip; cd corefx .

(tidak diperlukan dari mesin Windows)

• Jalankan tes:

./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

Ia mengatakan:

40 tes gagal

Saya tidak berpikir fakta bahwa beberapa rakitan tidak dapat membangun/berfungsi untuk FreeBSD namun harus menjadi penghalang utama untuk menguji sisanya.

Saya harus setuju dengan yang satu ini. Lebih baik memulai QA pada pekerjaan yang telah kita lakukan, daripada menunggu semuanya selesai sebelum memulai pengujian.

Dikatakan: 40 tes gagal

40 dari berapa? Di stadion baseball mana kita? :)

40 dari berapa? Di stadion baseball mana kita? :)

mengalahkan saya juga. Tes muncul dari rakitan tes (dll terkelola) dan jumlah total tes tidak terlihat.

Jumlah yang dihasilkan skrip di bagian akhir adalah jumlah rakitan uji yang gagal. xUnit harus menulis jumlah tes yang gagal per perakitan ke stdout sebagai bagian dari menjalankannya. Angka-angka juga harus dalam file XML yang dihasilkannya di setiap folder perakitan pengujian.

Bisa jadi runtime juga hanya mogok dan dalam hal ini mungkin tidak ada log yang dihasilkan per rakitan pengujian.

@ jasonwilliams200OK Apakah Anda tahu jika ada kemajuan dalam masalah penandatanganan Majelis? Saya melakukan hal yang sama di Ubuntu. Jika tidak ada yang mengerjakannya, mungkin kita harus membuka edisi terpisah untuknya.

@naamunds , yang telah diperbaiki pada master CoreFX sebagai bagian dari https://github.com/dotnet/corefx/issues/3739 .

Pembaruan - Hari ini saya menjalankan tes di FreeBSD, ribuan dari mereka lulus dan kemudian beberapa gagal karena kurangnya System.Diagnostics.Process dan teman-teman snafu. Setelah ~40 menit eksekusi yang berhasil, itu tergantung pada tes System.IO.FileSystem (sekitar ~15 menit sebelum saya menekan Ctrl+C untuk mengakhiri).

@ jasonwilliams200OK bagaimana Anda berhasil mengkompilasi corefx di bawah freebsd? Saya terjebak pada kesalahan tentang gssapi

@sec , pada saat membuat catatan ini: https://Gist.github.com/jasonwilliams200OK/6efa7907e66275df2d24 , GSSAPI tidak diperlukan oleh CoreFX. Namun, sepertinya pkg baru-baru ini di-porting ke FreeBSD: http://www.freshports.org/security/p5-GSSAPI. Anda mungkin ingin mencoba pkg upgrade pkg && pkg update && pkg install p5-GSSAPI .

@jasonwilliams200OK , saya sudah mendapatkan ini (ini perl ext. btw.) Masalah tidak ada gssapi_ext.h. Triknya adalah melakukan "pkg install krb5" - sekarang dikompilasi asli.
Saya telah menyalinnya ke coreclr runtime, tetapi masih tidak dapat menjalankan aplikasi ASP.NET Core :) pertarungan berlanjut.

Apa status tugas ini saat ini? Apakah daftar @janhenke lengkap dan akurat? Apakah semua pekerjaan yang perlu dilakukan, sudah selesai? Maka itu harus ditutup, kan?

Jika demikian, mengapa kita masih memiliki tugas ini? https://github.com/dotnet/corefx/issues/2070

Jika masih ada pekerjaan yang harus diselesaikan, apakah masalah baru harus didaftarkan berdasarkan keadaan saat ini?

Saya pikir ini juga diperlukan - dotnet/corefx#2046

haruskah masalah baru didaftarkan berdasarkan keadaan saat ini?

Ya :+1:

Kami mendiskusikan port berbasis komunitas untuk FreeBSD dengan @RussellHaley (dari komunitas FreeBSD) dan @wfurt (dari tim .NET Core) yang keduanya menyatakan minatnya pada pekerjaan tersebut.
Berikut proposal rencana yang kami susun (umpan balik/saran dipersilakan):

1. Menghasilkan binari di repo CoreCLR & CoreFX yang menargetkan FreeBSD - menggunakan peretasan tidak masalah
   
   
   
   • Sulit untuk diparalelkan, @wfurt akan mengerjakannya
   
   
   • Build dapat berupa campuran build dari platform lain (Mac, Linux) yang menargetkan FreeBSD
   
   
   • Kami memerlukan langkah-langkah yang terdokumentasi (pada wiki FreeBSD) untuk mereproduksi build dengan perbaikan bug khusus FreeBSD
   
   
2. Jalankan & stabilkan tes CoreCLR (menggunakan corerun)
   
   
   
   • Tes dapat dibangun di platform lain
   
   
   • Sasaran: Memberikan kualitas dasar waktu proses
   
   
3. Jalankan & stabilkan tes CoreFX (menggunakan corerun)
   
   
   
   • Tes dapat dibangun di platform lain
   
   
   • Perhatikan ini membutuhkan xunit. Kami percaya, berdasarkan pengalaman porting kami sebelumnya, setelah [2] selesai, xunit hanya akan berfungsi.
   
   
   • Ini secara teori dapat diparalelkan dengan [2] - mungkin memerlukan pintasan xunit (misalnya menghasilkan resep eksekusi statis di platform lain)
   
   
4. Full stack build di FreeBSD (menggunakan corerun sebagai bootstrap dari [1]-[3])
   
   
   
   • Kami akan membutuhkan semua alat (nuget, msbuild, roslyn) untuk bekerja pada boostrapping .NET Core
   
   
5. Pemasang (port FreeBSD)
   
   
   
   • Tahap pertama: Menggunakan binari produk dari umpan nuget
   
   
   • Tahap kedua: Bangun produk dari sumber (diblokir saat membangun dari upaya sumber)
   
   
   • Memerlukan keahlian komunitas FreeBSD dan panduan tentang desain
   
   
   • Catatan: Kami juga dapat menautkan paket FreeBSD dari halaman unduhan .NET Core resmi sebagai paket dukungan komunitas
   
   
6. Pembuatan dan pengujian reguler di FreeBSD
   
   
   
   • Sasaran: Pastikan perubahan dalam .NET Core repo yang melanggar FreeBSD diketahui lebih awal
   
   
   • Desain yang dibutuhkan
   
   
   • Memerlukan keahlian komunitas FreeBSD dan panduan tentang desain
   
   

Prinsip operasi:

• Perubahan [2]-[4] harus dilakukan terutama di repo CoreCLR/CoreFX (karena persyaratan penandatanganan CLA, tinjauan kode dari ahli/anggota tim Inti .NET, dll.)
• Kami akan melacak pekerjaan tingkat tinggi tentang masalah ini. Bug tertentu akan diajukan sebagai masalah terpisah.

Jika ada yang tertarik untuk membantu, beri tahu kami di sini. Kita dapat dengan mudah mendistribusikan item pekerjaan dari [2] & [3] di atas setelah kita cukup jauh dengan [1].

Versi terbaru dari proposal ada di postingan teratas edisi ini.

Menandai lebih banyak orang yang menyatakan minat pada daftar freebsd-mono ( thread ini ): @smortex @radovanovic @Echo-8-ERA

BTW: Saya tidak dapat menemukan akun Mathieu Prevot GitHub -- [UPDATE] Ditemukan di https://github.com/dotnet/corefx/issues/1626#issuecomment -330348424: @mprevot

Untuk NetBSD kami kehilangan mutex posix yang kuat, ini adalah satu-satunya fitur yang masih belum ada untuk menghasilkan mutex yang bernama robus. Kami sekarang dapat men-debug kegagalan kode terkelola dengan LLDB/NetBSD.. ini berfungsi baik dengan file inti. Dalam upaya saya sebelumnya, kami mati karena kurangnya fitur ini di LLDB (saya mulai mem-port debugger ini untuk .NET).

Memiliki dukungan FreeBSD yang lebih baik akan sangat membantu.

Ada juga masalah di masa lalu dengan kurangnya dukungan tamu hyperv untuk melampirkan buildbot NetBSD ke mesin CI dan memverifikasi tambalan... untuk ini saya mungkin memerlukan bantuan dari MS. Saya berharap ada perangkat lunak berpemilik yang diperlukan untuk menjalankannya, yang tidak saya miliki... Saya mungkin menemukan pengembang untuk melakukan pekerjaan itu jika ada kepentingan bersama (investasi) antara The NetBSD Foundation dan Microsoft.

Di mana kita kehilangan "mutex posix yang kuat"? Apakah ini bagian dari .NET Core PAL?

Sistem CI mana yang Anda maksud? Mengapa itu terkait dengan upaya port .NET Core?

Di mana kita kehilangan "mutex posix yang kuat"?

Di kernel NetBSD (dan libc/libpthread), ini adalah bagian dari CoreCLR. FreeBSD mengembangkannya dalam dua tahun terakhir. Mungkin tersedia dalam rilis stabil terbaru.. tetapi perlu diperiksa.

Saya ingin menambahkan fitur ini sebelum saya memulai ulang port .NET. (Ada juga terdeteksi API kecil yang hilang untuk perutean jaringan .. tapi saya lewati sekarang).

Apakah ini bagian dari .NET Core PAL?

Saya tidak ingat sekarang, tanpa memeriksa kode - itu adalah API yang digunakan untuk mengimplementasikan .NET bernama mutex kuat (atau mungkin semaptores).

Sistem CI mana yang Anda maksud?

NetBSD.

Mengapa itu terkait dengan upaya port .NET Core?

Itu adalah fitur opsional terakhir kali saya melihat. Saya memutuskan untuk mendapatkan paritas fitur pada antarmuka kernel dan utilitas (seperti LLDB). Hanya gaya kerja saya, untuk mendapatkan blok bangunan fungsional dan kemudian membangun rumah. Pada titik tertentu kita akan tetap membutuhkannya, jadi mengapa tidak mengembangkannya sekaligus. Terima kasih atas pengertian :)

Mungkin Anda bisa menandai grup freebsd-dotnet di GH? Dia adalah anggota di sana (atau Anda bisa mencari nama akunnya). ‎Emailnya adalah [email protected]

[EDIT] Hapus email yang didengar & balasan sebelumnya oleh @karelz

@RussellHaley jangan ragu untuk menandai grup yang lebih besar jika menurut Anda itu pantas. Saya tidak dapat menemukan akun GH Mathieu melalui nama atau emailnya, itulah yang saya maksud di atas (BTW: Saya mem-ping dia melalui email secara langsung).

Saya akan melihat penandaan grup.

Ini akun Mathieu. Mungkin pengaturan privasi?

https://github.com/mprevot

Bersulang,

Rusia

Pada Senin, 18 Sep 2017 jam 13:01, Karel Zikmund [email protected]
menulis:

@RussellHaley https://github.com/russellhaley jangan ragu untuk menandainya
kelompok yang lebih besar jika Anda pikir itu tepat. Saya tidak dapat menemukan GH Math Mathieu
akun melalui nama atau emailnya, itulah yang saya maksud di atas.

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/dotnet/corefx/issues/1626#issuecomment-330338996 , atau bisukan
benang
https://github.com/notifications/unsubscribe-auth/ACENF_N6mtOo3fptvku-LUMioNpZG7coks5sjswWgaJpZM4EPG-N
.

Saya tidak dapat melihat di mana pun di sini disebutkan, tetapi versi FreeBSD terendah apa yang kami targetkan di sini (saya berasumsi setidaknya 10 dan yang lebih baru, tetapi mungkin juga 9)?
(Saya juga agak bingung diskusi apa yang harus dilakukan di milis mono @freebsd , dan apa di sini?)

Nah, jika Fedora adalah pilihan, MS hanya akan mendukung versi yang saat ini didukung, yaitu 10.3 (10,4 segera) dan 11.1.

@radovanovic FreeBSD 9 tidak didukung lagi, 10 akan EoL pada april 2018, 11 pada 2021. Dari pengalaman saya seharusnya tidak ada masalah dengan kompilasi pada 11 vs 10 (dan bahkan 9 jika Anda mau). FreeBSD dikembangkan dengan mempertimbangkan kompatibilitas ke belakang.

@radovanovic Saya juga agak bingung diskusi apa yang harus dilakukan di milis mono@freebsd , dan apa di sini?

Saya mengharapkan diskusi teknis, koordinasi pekerjaan dan status di sini karena ini adalah audiens yang lebih luas daripada milis mono@freebsd . OTOH kami tidak ingin ada trilyun diskusi acak tentang satu masalah, jadi kami mungkin mengambil beberapa diskusi desain khusus ke dalam masalah terpisah dari yang ini jika mereka tumbuh di atas jumlah balasan yang masuk akal.

Saya akhirnya bisa menjalankan tes corefx di FreeBSD 11.0 (tanpa tes outerloop)
Total lulus: 144208
Total gagal: 2622
Total dilewati 207

Saya akan memperbarui https://github.com/dotnet/corefx/wiki/Building-.NET-Core--2.x-on-FreeBSD dengan instruksi. Saya akan mengajukan masalah tertentu dan menandainya dengan os-freebsd dan up-for-grab.
Pertempuran skala penuh bisa dimulai. Dibutuhkan sukarelawan.

Dan ya, saya melewatkan langkah kedua yang diusulkan. Aku akan kembali ke sana juga.

Dengan beberapa perubahan pekerjaan dalam proses, statistik saat ini terlihat seperti:
Total lulus: 238892
Total gagal: 58
Total dilewati 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.Globalisasi.Tests.dll, 2
System.Drawing.Common.Tests.dll, 31
System.Console.Tests.dll, 2

dotnet/corefx#24538 dibuka untuk melacak dukungan cangkir yang rusak.

Kemajuan besar! Menambahkan NetBSD saat memiliki dukungan FreeBSD in-tree seharusnya sederhana.

@wfurt tolong bagikan alamat email, saya akan menjatuhkan beberapa baris.

Dukungan awal telah digabungkan ke cabang master. Build harus berfungsi seperti yang dijelaskan di halaman WIKI.
Saya perlahan maju di dotnet/corefx#24386 tetapi itu seharusnya tidak menahan sebagian besar pengguna.

Bisakah kita mem-bootstrap .NET di FreeBSD?

Saya belum mencoba untuk sementara waktu @krytarowski Ada dorongan untuk memperbarui perkakas ke rilis 2.0 dan saya menunggu upaya itu untuk menstabilkan. Saya akan mencobanya lagi dan saya akan memposting pembaruan.

Hai, jadi saya macet dengan tes yang dikelola clr tidak berjalan. https://pastebin.com/B5KhtKX5

Masukan apa pun akan sangat bagus karena itu telah menjadi masalah selama beberapa waktu. Saya juga baru-baru ini mengalami kegagalan build pada pembuatan corefx di Windows (master, revisi Git 749194e). https://pastebin.com/JXUySLTY

Saya berasumsi itu adalah masalah yang terputus-putus tetapi itu memperlambat saya malam ini.

Jika Anda melihat kesalahannya:

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

Dan baris kode yang menyinggung :

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

Perasaan saya adalah bahwa $maxProcesses tidak didefinisikan, yang mengarah ke ekspresi boolean yang tidak lengkap:

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

Ini harus cukup dapat diuji. Dan jika itu masalahnya, Anda hanya perlu pergi berburu ke belakang untuk mencoba mencari tahu bagaimana Anda berakhir seperti ini.

Terima kasih atas bantuan Anda! @josteink :) Anda benar. Patch ada di sini: https://Pastebin.com/d5y9k1tw

Ini memungkinkan tes berjalan, tetapi saya menyerah pada ~ 1000 kesalahan dengan sifat yang sama:

GAGAL - JIT/Metodis/gips/iface/_il_dbgiface2/_il_dbgiface2.sh
MULAI EKSEKUSI
/usr/home/russellh/Git/coreclr/bin/tests/Windows_NT.x64.Debug/Tests/coreoverlay/corerun _il_dbgiface2.exe
coreclr_initialize gagal - status: 0x80004005
Diharapkan: 100
Sebenarnya: 255
AKHIR EKSEKUSI - GAGAL

Oke, sesuai informasi yang sangat bagus dari @janvorli , saya menjalankan sebagian dari rilis build saya dan sebagian dari build in debug saya. Kesalahan salin/tempel yang memalukan. Saya sedang membangun kembali sekarang.

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

Patch ada di sini: https://Pastebin.com/d5y9k1tw

Jika Anda memiliki tambalan yang memperbaiki bangunan yang rusak, saya akan merekomendasikan mengirimkannya sebagai permintaan tarik sehingga diperbaiki untuk semua orang :)

Terima kasih, saya akan. Saya masih berusaha menjalankan tes dan saya tidak yakin apa yang menyebabkan kesalahan berikutnya tadi malam.

Saya kira dukungan Freebsd 11 "pkg install" untuk netcore 2.1 (setelah dirilis) tidak akan terjadi, bukan?

TLDR; Banyak pekerjaan telah dilakukan, tetapi perlu ada seseorang untuk mengantarnya pulang. Menulis port Makefile adalah bagian yang mudah.

@wfurt bisa mendapatkan CLR dan FX untuk membangun menggunakan Linux tetapi sebagian besar belum teruji. Saya bisa mendapatkan bagian 'asli' untuk dibangun di FreeBSD tetapi terhenti mendapatkan bagian yang dikelola untuk dibangun di Windows (untuk FreeBSD). Semuanya berantakan mentransfer file antara sistem operasi.

Secara terpisah di milis [email protected] , @dragonsa telah mengimpor versi biner Dot Net Core 1 dan semua rantai alat (msbuild, nuget dll) dari MintOS menggunakan emulasi Linux. Saya sudah bisa menggunakan tambalannya dan menjalankan beberapa alat tetapi tidak pernah sempat membangun apa pun. Saya tidak yakin apakah tambalan ini telah dilakukan; Saya sedang meninjau mereka dan saya berganti pekerjaan. Saya tidak memiliki DotNet dalam peran saya saat ini dan sedang meningkatkan hal-hal lain sekarang.

Apa arti semua itu? Jika seseorang dapat memverifikasi tambalan @dragonsa , dia dapat mendorong mereka ke pohon port, maka secara teknis dimungkinkan untuk membangun inti 2 di FreeBSD secara asli. Namun, seperti yang Anda lihat, ada banyak bagian kecil yang perlu disatukan dan diatur. Saya telah menjatuhkan bola itu sehingga seseorang perlu mengambilnya. Saya sarankan melompat di milis [email protected] . https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/eresources-mail.html

@russellhadley Terima kasih atas

Hai,

Membahas hal ini dengan .NET dev di sini, saya bersedia membantu pengembangan port/paket FreeBSD.

Pengungkapan penuh: Saya bukan pengembang .NET namun saya bersedia bekerja dengan siapa pun untuk memasukkan ini ke dalam pohon.

~cy

@cschuber Saya terlalu sibuk untuk mengawasi status saat ini, tetapi sebagai seseorang yang mengirimkan banyak patch FreeBSD dan berhasil menjalankan Hello World sekitar 3 tahun yang lalu, akan luar biasa jika akhirnya kami bisa melihat benda ini mendarat dengan benar. Anda memiliki dukungan penuh saya :)

@cschuber , masalah aktif saat ini adalah https://github.com/dotnet/coreclr/issues/18067. Terutama empat fitur ini yang tersisa https://github.com/dotnet/corefx/issues?q=is :open+ label:os-freebsd+label :up-for-grabs+is:issue , di antaranya adalah pengamat Filesystem yang paling rumit/merepotkan https://github.com/dotnet/corefx/issues/2046.

Terima kasih atas tawarannya @cschuber. Kami hampir mencapai titik ketika itu mungkin.
Kami baru-baru ini bekerja dengan @mateusrodrigues untuk membuat .net bekerja di FreeBSD dan dia mencoba membuat PowerShell berfungsi. Daftar @kasper3 yang dikirim sebagian besar adalah fitur yang hilang. Saya pikir kita bisa membuang PNSP untuk saat ini. Dari calon masalah saya yang paling mendesak adalah dotnet/corefx#30698 dan https://github.com/dotnet/coreclr/issues/18481. Akan sangat bagus jika siapa pun dari komunitas dapat menggalinya. Saya tidak menjalankan tes baru-baru ini, tetapi saya khawatir jumlah kegagalan meningkat.
Kita harus membuka masalah untuk setiap grup baru yang gagal.

Saya juga mulai memperbaiki source-build tetapi masih ada beberapa tantangan di depan.
c# compiler ditulis dalam c#. Pembuatan .net saat ini menggunakan versi .net sebelumnya untuk menghasilkan rakitan terkelola. Itu juga tergantung pada paket dari Nuget.
Saat ini, kami memiliki bootstrap cli yang cukup bagus sehingga kami dapat membangun coreclr, corefx dan beberapa repo lainnya di FreeBSD. Saya belum memperbarui instruksi pembuatan untuk mencerminkan perubahan 2.1 dan pembuatan sumber.

+1 Hanya sebuah catatan untuk mengatakan bahwa saya senang ini masih memiliki momentum. Sulit untuk diikuti dengan begitu banyak bagian yang bergerak tetapi sepertinya orang-orang membuat kemajuan. Saya membuat https://github.com/dotnet/coreclr/issues/6115 beberapa waktu lalu tetapi proyek yang saya kerjakan kemudian ditunda. Saya sangat berharap ini semudah pkg install dotnet && dotnet build suatu hari (tanpa linux compat).

Juga menantikan ini

Kami memiliki build harian sekarang. Seseorang bisa mendapatkan runtime atau SDK di sini: https://dotnetcli.blob.core.windows.net/dotnet/Runtime/master/dotnet-runtime-latest-freebsd-x64.tar.gz dan
https://dotnetcli.blob.core.windows.net/dotnet/Sdk/master/dotnet-sdk-latest-freebsd-x64.tar.gz

Hal ini juga memungkinkan untuk cross-target misalnya di Linux atau Windows seseorang dapat melakukan dotnet publish -r freebsd-x64 dan itu akan membuat aplikasi FreeBSD mandiri.

Ini masih belum lengkap dan tidak didukung tetapi harus memudahkan siapa saja untuk berkontribusi.
Akan sangat bagus jika orang dapat mencobanya, melaporkan masalah.
Juga ini akan menjadi saat yang tepat untuk dorongan terakhir untuk menutup celah fitur dan memperbaiki bug.

cc: @mateusrodrigues

Kerja bagus,

Ketika saya mengusulkan komitmen FreeBSD pertama saya sekitar 2-3 tahun yang lalu, saya sebenarnya tidak percaya kami akan sampai di sini, tetapi saya tentu ingin mencobanya.

Ini jelas merupakan tonggak besar dan mudah-mudahan akan memudahkan kontributor baru membantu menyelesaikan pelabuhan.

Terima kasih banyak untuk semua orang yang membantu kami sampai sejauh ini 👍

Kemajuan besar! Saya masih berjuang dengan toolchain (sebagian besar proyek LLVM selain LLDB dan LLD selesai) dan virtualisasi yang dibantu perangkat keras untuk NetBSD (Linux/BSD sekarang mulai boot hingga pengecualian fatal VTx, OS yang lebih sederhana seperti FreeDOS sudah berfungsi) .. jadi saya akan melanjutkan porting NetBSD saya, semoga lebih cepat. Dukungan FreeBSD yang lebih baik akan membantu resume yang lebih mudah.

Luar biasa :)

Kami celwbrate mabuk kenapa ensil bombsrdment??

@krytarowski Bisakah Anda mengembangkan cara 'dukungan FreeBSD' menjadi lebih baik?

Akan sangat bagus jika beberapa guru FreeBSD dapat melihat https://github.com/dotnet/coreclr/issues/22124 Saya berharap binari membangun untuk 11 berjalan pada 12 tetapi tampaknya tidak demikian;(
Sangat mudah untuk mereproduksi dengan aplikasi sederhana dan rilis 12.0 tampaknya memecahkan sesuatu yang bergantung pada dotnet.

Hai, saya bukan guru tetapi kami menemukan regresi threading di 12-RELEASE di port Lua53.
Lihat di sini untuk bug asli: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235158
dan di sini untuk bug sistem dasar yang diidentifikasi: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235211 (perhatikan bug sistem dasar mengidentifikasi kode yang dapat digunakan untuk mereproduksi masalah untuk perbandingan).

Perbaikan untuk Lua adalah menautkan ke -pthread, meskipun ada persyaratan NOL dari Lua untuk -pthread.

terima kasih @RussellHaley. Itu terlihat seperti prospek yang menjanjikan.

Senang aku dapat membantu. Saya ingin bermain bersama tetapi saya hampir tidak memiliki beberapa jam yang dibutuhkan untuk memelihara pelabuhan Lua. Pertahankan pekerjaan hebat!

Sebagai orang yang memperbaiki implementasi threading FreeBSD di coreclr , saya pikir pthreads digunakan cukup konsisten di seluruh, karena itulah yang harus saya tambal untuk membuat build berjalan.

Yang mengatakan, mungkin ada tetapi dan bagian yang mendasari yang tidak pernah saya sentuh yang menggunakan utas "biasa" ...

Mungkin orang lain yang tahu lebih banyak tentang implementasi umum dapat bergabung? @janvorli ?

Ini memperbaiki masalah bagi saya:

[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

Saya tidak melakukan tes ekstensif tetapi setidaknya saya dapat menjalankan dotnet lagi.

Ok, saya dapat melihat bahwa dotnet executable tidak terhubung dengan pthreads untuk sistem lain selain Linux.
https://github.com/dotnet/core-setup/blob/2ef0b64810530961f492c33d37fc7509128e0a9b/src/corehost/cli/exe.cmake#L59 -L61

Apakah itu berarti jawaban untuk memperbaikinya sesederhana kedengarannya? Yaitu sesederhana ini? https://github.com/josteink/core-setup/commit/25657ba2e181cce401acd7f4bf9d27a08a668470

Jika demikian, saya akan dengan senang hati menjadikannya PR.

Ya saya pikir begitu. Saya menunggu @joperator untuk mengkonfirmasi.
Tidak yakin apakah kami membutuhkan "dl" juga, tetapi itu dapat diselesaikan ketika Anda mengirimkan PR @josteink

Benar. Salahku. Jadi lebih seperti ini: https://github.com/josteink/core-setup/commit/a08f38e25a98c25f59c8ed8c8567a0cb08b1c1c6

Saya telah membuat PR untuk itu. Beri tahu saya jika perlu diubah: https://github.com/dotnet/core-setup/pull/5072

Benar. Salahku. Jadi lebih seperti ini: josteink/ core-setup@a08f38e

Saya telah membuat PR untuk itu. Beri tahu saya jika perlu diubah: dotnet/core-setup#5072

Sekedar FYI, sepertinya ini sudah ditambal di sistem dasar: https://reviews.freebsd.org/D18988

Sepertinya masalah utama di dotnet/coreclr#22124 sudah diperbaiki @wfurt.
Saya hanya memiliki masalah ketika mencoba mempublikasikan aplikasi mandiri di FreeBSD 12.0.

paket NuGet resmi freebsd-x64 telah dihapus sejak pratinjau .NET Core 3.0 2 dan kami tidak dapat memublikasikan aplikasi untuk FreeBSD sejak saat itu. Apakah ada rencana untuk mengaktifkannya kembali di 3.0?

Sayangnya, kami harus menurunkan prioritas untuk memunculkan FreeBSD (karena berbagai alasan dan kesulitan dalam dukungan Azure end-to-end) dan itu tidak akan menjadi prioritas di .NET Core 3.0.
Kami ingin membuatnya tetap semi-berfungsi di keadaan seperti sekarang, tetapi kami tidak punya banyak waktu untuk berinvestasi sekarang :(.

@karelz Terima kasih atas balasan Anda dan saya memahami pekerjaan yang diprioritaskan dari .NET Core 3.0. Saya akan fokus membawa aplikasi saya dengan emulasi FreeBSD Linux. :)

@hjc4869 Atau Anda dapat mencoba mono. IIRC, ini akan mendukung .NET Standard 3.0

Saya berencana untuk mencobanya lagi tetapi seperti yang disebutkan @karelz itu bukan prioritas untuk 3.0

@newsash Mono adalah opsi yang dapat diterima bagi saya. Namun saya merasa sulit untuk membangun proyek saya dengan target mono yang ditambahkan ke file .NET Core csproj yang ada.

Pada mesin Linux saya mencoba menambahkan net472 ke TargetFrameworks dan mengatur variabel FrameworkPathOverride tetapi itu tidak berfungsi dengan baik. Jika saya menggunakan API yang diimplementasikan di mono dan .NET Core, tetapi tidak .NET Framework, itu akan gagal dibangun dengan mono. Selain itu, meskipun mono mendukung .NET Standard 2.1, saya masih tidak dapat menambahkan referensi ke .NET Standard 2.1 dll dalam net472 csproj.

Haruskah saya menambahkan csproj terpisah dan menggunakan mono msbuild daripada menggunakan alat dotnet, atau apakah Anda punya saran tentang masalah ini?

Hanya komentar cepat.

Dengan mono yang akan ditelan oleh .NET 5 sesuai pengumuman baru-baru ini [1], memberikan dukungan yang layak untuk FreeBSD telah menjadi hal yang mendesak.

Mono telah terbukti memiliki dukungan lintas platform yang sangat baik dan dapat dibangun tanpa masalah dari port FreeBSD. Banyak toko menjalankan beban .net mereka di FreeBSD karena OS ini memiliki banyak fitur unik. Sejauh ini, mono telah menjembatani kesenjangan tetapi dengan .NET 5 tampaknya dalam waktu dekat, mono akan digabungkan ke dalam NET 5 dan komunitas FreeBSD akan benar-benar terputus dari ekosistem .NET.

Dotnet harus memiliki dukungan FreeBSD yang matang sebelum hal ini terjadi.

Saya pikir Microsoft harus secara resmi mendukung FreeBSD pada saat ini dan memastikan semua perkakas dotnet dibangun di platform ini.

@jasonpugsley menyusun instruksi https://github.com/jasonpugsley/core-sdk/wiki/.Net-Core-3.0.0-for-FreeBSD dan @joperator mencoba membuat source-build berfungsi https://github. com/dotnet/source-build/issues/1139

Kami memiliki ~ 30 tes terakhir yang gagal untuk corefx.

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 sedang melihat System.Diagnostics.Tests.ProcessTests sehingga tes penguncian yang gagal tampaknya merupakan celah terbesar yang tersisa. Akan sangat bagus jika ada yang bisa melihat dotnet/corefx#30899.

Hanya ingin tahu apakah ada pembaruan tentang ini atau sudah ditinggalkan?

@elfalem , akhir-akhir ini FreeBSD CI leg (yang dikompilasi silang dari Ubuntu) berjalan di dotnet/runtime PRs. Ini menggunakan gambar buruh pelabuhan dari https://github.com/dotnet/dotnet-buildtools-prereqs-docker/ , yang telah menginstal semua prereqs. Kita dapat menggunakan wadah buruh pelabuhan yang sama untuk menerbitkan paket runtime (pada dasarnya tar.gz), secara lokal atau mesin jarak jauh. misalnya kita dapat mengatur GitHub Action di salah satu cabang fork kita, seperti: https://github.com/am11/runtime/blob/feature/freebsd/ci/.github/workflows/main.yml , yang mengunggah artefak untuk rilis GitHub pada tag push https://github.com/am11/runtime/releases/tag/6.0.0-dev.freebsd.1. Arsip dotnet-runtime-6.0.0-dev-freebsd-x64.tar.gz dalam hal ini memiliki cukup bit untuk menjalankan aplikasi dotnet yang diterbitkan (dari sistem linux/mac yang berbeda, yang memiliki dotnet SDK). Saya mengujinya dengan membuat VM 12.2 baru (gelandangan), mengekstrak dan menyalin aplikasi yang diterbitkan dari mac ke VM, itu berhasil:

#!/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!

Saya pikir @Thefrank sedang mencari cara untuk membuat paket FreeBSD Ports yang tepat di beberapa titik.

Hanya ingin tahu apakah ada pembaruan tentang ini atau sudah ditinggalkan?

Anda mungkin ingin melihat https://github.com/dotnet/source-build/issues/1139
Saya belum mencoba baru-baru ini karena saya menunggu final dotNET5 tetapi, pada beberapa bulan yang lalu, runtime FreeBSD hanya dapat dibangun sebagai kompilasi silang di Linux. ASPNet dan SDK juga memerlukan kompilasi silang Linux tetapi hanya dibangun jika bintang-bintang sejajar (pembaruan arcade atau bot otomatis lainnya tidak merusak ketergantungan)

edit: dan @ am11 memposting tulisan yang lebih baik saat saya mengetik
edit2: lupa tanda baca dan sepertinya final dikeluarkan 2 hari yang lalu. kira saya harus mulai mengerjakan itu atau sesuatu

Selain semua hal di atas, saya membuat proyek FreeBSD di https://github.com/dotnet/runtimelab/ dan saya perlahan-lahan membuat paket yang dibangun dan diterbitkan. Tujuannya adalah untuk membangun dan memublikasikan cukup banyak aplikasi untuk berjalan di FreeBSD dan memiliki seed untuk source-build.

Saya pikir saya akan menulis pembaruan cepat. Saya akhirnya mendapatkan semua planet yang selaras untuk membangun 5.0.0 RTM di FreeBSD. Saya tidak mengikutinya sejak Pratinjau3 dan butuh beberapa saat (dan _banyak_ upaya membangun) untuk menemukan kombinasi yang tepat dari build yang kompatibel untuk mendapatkan versi 5.0.
Saya dapat membangun PowerShell 7.1.0 dengan sedikit peretasan yang mengejutkan, ini berfungsi meskipun saya belum mengujinya secara menyeluruh tetapi sepertinya ini adalah tes SDK yang bagus.
Saya baru saja membangun AspNetCore tetapi saya belum mengujinya sama sekali.

$ 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>

Satu-satunya masalah dengan melakukan pekerjaan ini secara manual (yaitu di luar sistem CI) adalah masalah yang disebabkan oleh pemutusan perubahan yang memerlukan build tertentu agar tersedia untuk build berikutnya untuk digunakan. Itu tidak sering terjadi tetapi membutuhkan banyak percobaan dan kesalahan untuk menemukan komit yang benar. Memiliki cross-build linux di sistem CI harus memperbaikinya tetapi saya belum melihatnya. Tetap baik untuk mengetahui bahwa saya dapat membuat SDK lengkap dan kemudian menggunakan SDK itu untuk membangun sesuatu yang lain.

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

Itu kemajuan yang bagus @jasonpugsley. Saya mencoba menemukan jawaban yang lebih baik untuk build tetapi saya tidak dapat meluangkan waktu yang layak dalam beberapa bulan terakhir ;(
Apakah PowerShell memberi Anda kesedihan karena terminfo atau apakah Anda menyalin definisi terminal dari tempat lain?

Saya mengambil definisi terminal dari Mac saya tempat saya berasal.

@jasonpugsley Anda jauh di depan saya. core dan sdk build dari linux cross freebsd. berjalan dengan baik dari pengujian terbatas yang saya lakukan. baik runtime maupun sdk crossbuilts tidak dapat membangun di freebsd sendiri (linux dan freebsd menggunakan llvm9 dan dentang9).
ld: error: /root/runtime/artifacts/obj/coreclr/FreeBSD.x64.Release/src/dlls/dbgshim/dbgshim.exports:1: unknown directive: V1.0
sakit sedikit lebih banyak jika saya punya lebih banyak waktu akhir pekan ini dan juga melihat apakah saya setidaknya bisa mendapatkan aspnetcore yang dibangun di linux untuk freebsd

@Thefrank , maksud Anda:

$ 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

gagal atau binari di artifacts/packages/Release/Shipping/dotnet-runtime-5.0.0-dev-freebsd-x64.tar.gz gagal dijalankan?
Jika Anda mencoba mengkompilasi silang SDK 5x di Ubuntu 18 atau 20, Anda mungkin ingin menerapkan tambalan ini https://github.com/dotnet/sdk/commit/80e42f16422352f725d78be72071781d8365a238 (ada di cabang master).

Saya benar-benar harus berhenti membuat posting ketika setengah tertidur.
Pembangunan runtime dan SDK selesai di linux.
Binari tersebut berjalan di freebsd (dotnet --info, konsol baru, dan jalankan)
Binari tersebut tidak dapat membuat runtime atau SDK dari sumber di freebsd

baiklah. Saya belum mencoba dogfodding binari stage0 untuk membangun kembali runtime di FreeBSD sebagai HostOS.

ld: kesalahan: /root/runtime/artifacts/obj/coreclr/FreeBSD.x64.Release/src/dlls/dbgshim/dbgshim. ekspor:1 : arahan tidak diketahui: V1.0

Mungkin ada baiknya melaporkan masalah ini secara terpisah. Kemungkinan ada beberapa cara untuk memperbaikinya, tetapi apakah tambalan ini membuat perbedaan:

--- 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)

apakah tambalan ini membuat perbedaan?

Saya berharap FreeBSD mengikuti Linux sejauh skrip versi simbol berjalan, bukan Darwin. IMO kemungkinan besar masalahnya adalah ada sesuatu yang spesifik GNU-awk di generateversionscript.awk

tambalan mengubah kesalahan:
ld: error: /root/runtime/artifacts/obj/coreclr/FreeBSD.x64.Release/src/dlls/dbgshim/dbgshim.exports:1: unknown directive: _CreateProcessForLaunch
jika masalah versi awk:

awk --version
awk version 20121220 (FreeBSD)

Jika mudah untuk bereksperimen, dapatkah Anda mencoba menginstal paket gawk dan mengubah permintaan di file CMake menjadi gawk?

mengembalikan patchnya. dipasang gawk pkg.
terlalu malas untuk mencari tahu bagaimana skrip build.sh melewati argumen cmake karena tidak langsung masuk akal jadi saya hanya menghubungkan gawk->awk.
kesalahan asli yang sama
ld: error: /root/runtime/artifacts/obj/coreclr/FreeBSD.x64.Release/src/dlls/dbgshim/dbgshim.exports:1: unknown directive: V1.0

edit terlambat: sepertinya binari di linux tidak dibangun dengan benar:

# ./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

terutama RID: osx-x64 mungkin menyebabkan beberapa masalah

terutama RID: osx-x64 mungkin menyebabkan beberapa masalah

RID tersebut ditampilkan oleh SDK setelah beberapa resolusi platform yang didukung vs. yang tidak didukung. Ini pada dasarnya tidak berpengaruh pada eksekusi aplikasi. RID sebenarnya yang terdeteksi oleh runtime sudah benar, jika tidak, aplikasi (seperti dotnet(1) ) tidak akan dijalankan dengan benar.
c# using System; using System.Runtime.InteropServices; class Program { static void Main() => Console.WriteLine("Real RID: {0}", RuntimeInformation.RuntimeIdentifier); }
mencetak Real RID: freebsd.12-x64 di kotak saya.

Dibuka #45663 untuk melacak masalah ld. Saya juga bisa mereproduksi.

@Thefrank mengenai kesalahan ld, coba ini:

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)

Itu akan mengaktifkan klausa else di eng/native/functions.cmake sini:

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()

Sejujurnya, saya bukan ahli linker jadi saat ini bekerja, saya tidak melihat lebih dalam untuk melihat apa yang sebenarnya diperlukan/kanonik untuk dentang di FreeBSD.

Ahh, masalah agen pengguna linker menyerang lagi. String versi LLD menyertakan (compatible with GNU linkers) dalam upaya untuk turun ke jalur tes konfigurasi ld GNU tetapi jelas tidak cukup pintar untuk kasus ini :)

Pencocokan pada LLD terlihat bagus di sini meskipun flag LD_GNU sekarang agak salah nama.

Ya itu membutuhkan lebih banyak pekerjaan. Nama bendera sekarang membingungkan. Tolong jangan ada yang mencoba melakukan ini apa adanya.

Dari: pemberitahuan Ed [email protected]
Dikirim: Senin, 7 Desember 2020 10:26:48
Kepada: dotnet/runtime [email protected]
Cc: Jason Pugsley [email protected] ; Sebutkan [email protected]
Perihal: Re: [dotnet/runtime] Dukungan untuk FreeBSD (#14537)

Ahh, masalah agen pengguna linker menyerang lagi. String versi LLD termasuk (kompatibel dengan tautan GNU) dalam upaya untuk turun ke jalur tes konfigurasi GNU ld tetapi jelas tidak cukup pintar untuk kasus ini :)

Pencocokan pada LLD terlihat bagus di sini bahkan jika bendera LD_GNU sekarang agak salah nama.

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub https://github.com/dotnet/runtime/issues/14537#issuecomment-739583816 , atau berhenti berlangganan https://github.com/notifications/unsubscribe-auth/AECFDEXKTDFRAX4ZEE6VXZTSTQHLRANCNFSM4TS3XPPA .

Saya memilih untuk menggunakan https://github.com/dotnet/runtime/pull/45664
Clr membangun hingga subset Clr.Tools kemudian gagal dengan

/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]

subset "mono" dan subset "libs" lengkap tanpa kesalahan

@Thefrank Ini adalah bagian kedua dari perbedaan ini yang Anda butuhkan untuk memperbaiki masalah itu:

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>

Mungkin lebih baik ditambahkan ke baris LINUX sebagai OR dalam kondisi.

@jasonpugsley yang berhasil!
/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):
Saya tahu saya lupa melakukan sesuatu beberapa hari yang lalu! Ini harus menarik

edit: tanpa crossgen (alias hanya babak kedua)

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

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

Time Elapsed 00:12:05.56

edit edit terakhir pada posting ini saya bersumpah:
Saya tahu tes bisa memakan waktu cukup lama dan itu mengatakan tes berjalan lama tapi ini tidak terkendali untuk satu tes
System.Net.HttpListener.Tests: [Long Running Test] 'System.Net.Tests.HttpListenerResponseTests.AddLongHeader_DoesNotThrow', Elapsed: 00:36:20

membunuh tes setelah menunggu 2 jam tes lain masih gagal

/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').