Runtime: फ्रीबीएसडी के लिए समर्थन

जहां तक https://github.com/dotnet/corefx/issues/1576 का संबंध है, सहमति बनती दिख रही है।

जब हमारे पास https://github.com/dotnet/corefx/issues/1625 पर भी कोई निर्णय होता है तो हमें कुछ कोड शिपिंग शुरू करने में सक्षम होना चाहिए।

dotnet/runtime#14536 पर समझौता पोर्टटीम द्वारा किया गया है, जब तक कि MSFT अन्यथा नहीं चुनता है, यह FreeBSD । मुद्दा डॉटनेट/कोरएफएक्स#1999 संभावित रूप से वह मुद्दा होगा जो सार्वजनिक एपीआई में परिभाषा पेश करता है।

dotnet/runtime#14536 पर समझौता पोर्टटीम द्वारा किया गया है, जब तक कि MSFT अन्यथा नहीं चुनता, यह FreeBSD होगा

अगर मैं इसे सही पढ़ता हूं, तो इसका मतलब है कि जब https://github.com/dotnet/corefx/pull/1999 का विलय हो जाता है, तो हम इस MSFT को नए सार्वजनिक एपीआई को मंजूरी देने पर विचार कर सकते हैं, और इसलिए शेष मुद्दों पर आगे बढ़ सकते हैं MSFT अनुमोदन की आवश्यकता के बिना नियमित पुल-अनुरोध।

अगर ऐसा है तो यह मुझे अच्छा लगता है।

https://github.com/dotnet/corefx/pull/1999#issuecomment -111279577 के अनुसार अगले चरण हैं:

1. "फ्रीबीएसडी पोर्ट टीम" उत्पादित कोरएफएक्स का एक फ्रीबीएसडी संस्करण प्राप्त करने के लिए अपना काम जारी रखती है (डॉटनेट / कोरएफएक्स # 1626 द्वारा ट्रैक किया गया)।
2. पोर्ट टीम FreeBSD पर पर्याप्त CoreFX और CoreCLR स्टैक लाती है ताकि हम FreeBSD पर CoreFX यूनिट परीक्षण चलाना शुरू कर सकें।
3. परीक्षण कुछ न्यूनतम गुणवत्ता स्तर तक पहुंचते हैं। मुझे नहीं पता कि यह अभी तक कैसा दिखता है, लेकिन मुझे उम्मीद है कि इसका मतलब कुछ ऐसा है जैसे अधिकांश परीक्षण पास हो जाते हैं। आदर्श रूप से हमारे पास केवल फ्रीबीएसडी के लिए अक्षम विशिष्ट परीक्षणों का एक समूह नहीं होगा (लिनक्स और ओएसएक्स की तुलना में, हम फ्रीबीएसडी को हमारे पास मौजूद अन्य * एनआईएक्स प्लेटफॉर्म की तुलना में उच्च मानक पर नहीं रखना चाहेंगे)।
4. फ्रीबीएसडी पोर्ट टीम के साथ काम करते हुए, कोरएफएक्स टीम को फ्रीबीएसडी पर चलने वाले हमारे सीआई सिस्टम में जोड़ा गया कोरएफएक्स परीक्षण मिलता है।
5. इश्यू डॉटनेट/रनटाइम#14536 के आधार पर पीआर को मर्ज करने पर चर्चा करें, जो संपत्ति को जोड़ता है।

यह मेरे लिए पूरी तरह से उचित योजना की तरह लगता है।

ठीक है, तो चलिए 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.

फ्रीबीएसडी पर कोरएफएक्स के निर्माण में पहली बाधा मोनो लगती है

एफडब्ल्यूआईडब्ल्यू, मुझे व्यक्तिगत रूप से नहीं लगता कि यह पहली बाधा है। निर्माण से संबंधित दो मुद्दे हैं:

1. फ्रीबीएसडी पर सही ढंग से काम करने वाली असेंबली का निर्माण
2. उन विधानसभाओं को FreeBSD पर बनाना

(1) महत्वपूर्ण है, और क्या मुझे विश्वास है कि यह मुद्दा किस बारे में है। (2) होना बहुत अच्छा है, लेकिन इसका अभाव फ्रीबीएसडी पर प्रबंधित कोड चलाने के लिए एक महान प्रणाली के निर्माण को नहीं रोकता है।

आप निश्चित रूप से प्राथमिकता देने के लिए स्वतंत्र हैं, हालांकि आप फिट देखते हैं, लेकिन मेरी सिफारिश (2) के बजाय (1) पर ध्यान केंद्रित करने की होगी।

ध्यान दें कि हमारे पास अभी भी Linux पर corefx बनाने और OSX पर इसे बनाने में समस्याएँ हैं, जैसे कि हमारा CI सिस्टम विंडोज़ पर उन प्लेटफ़ॉर्म के लिए असेंबली बनाता है; इसके बाद यह परिणामी असेंबली को परीक्षणों को निष्पादित करने के लिए लक्ष्य प्लेटफॉर्म पर बंद कर देता है।

यह काफी उचित है। मैंने अभी यह माना है कि अगर हम वास्तव में इसे फ्रीबीएसडी पर स्वयं बना सकते हैं तो कोरएफएक्स में बेक किए गए सामान्य फ्रीबीएसडी प्लेटफॉर्म समर्थन प्राप्त करना आसान होगा।

मैं अभी के लिए विंडोज द्वारा शुरू की गई बिल्डिंग के साथ काम करूंगा और एक बिल्ड-कॉन्फ़िगरेशन को एक साथ निंजा करने का प्रयास करूंगा।

@ जोस्टिंक बीटीडब्ल्यू । corefx को अब मोनो 4.0.1.44 पर निर्माण करना चाहिए।

@akoeplinger नाइस। इससे मुझे कुछ उम्मीद है कि हम इसे फ्रीबीएसडी पर भी चला सकते हैं :)

अच्छे अंक। हालाँकि, यदि हम वास्तव में चाहते हैं कि corefx FreeBSD वातावरण का हिस्सा बने, तो हमें वास्तव में इसे पोर्ट सिस्टम में लाने के लिए स्रोत से संकलित करने में सक्षम होने की आवश्यकता है।

मैंने सुना है कि मोनो 4.0.1.44 इनमें से बहुत से मुद्दों को ठीक करता है लेकिन अभी तक इसके साथ खेलने का समय नहीं मिला है। मुझे पता है कि पोर्ट टीम मेकफाइल पोर्ट को अपडेट कर रही है और साथ ही हम एक नए पैच के साथ बात कर रहे हैं।

12 जून 2015 को, 20:21 बजे, स्टीफन टुब नोटिफिकेशन @github.com ने लिखा:

फ्रीबीएसडी पर कोरएफएक्स के निर्माण में पहली बाधा मोनो लगती है

एफडब्ल्यूआईडब्ल्यू, मुझे व्यक्तिगत रूप से नहीं लगता कि यह पहली बाधा है। निर्माण से संबंधित दो मुद्दे हैं:

फ्रीबीएसडी पर सही ढंग से काम करने वाली असेंबली का निर्माण
उन विधानसभाओं को FreeBSD पर बनाना
(1) महत्वपूर्ण है, और क्या मुझे विश्वास है कि यह मुद्दा किस बारे में है। (2) होना बहुत अच्छा है, लेकिन इसका अभाव फ्रीबीएसडी पर प्रबंधित कोड चलाने के लिए एक महान प्रणाली के निर्माण को नहीं रोकता है।

आप निश्चित रूप से प्राथमिकता देने के लिए स्वतंत्र हैं, हालांकि आप फिट देखते हैं, लेकिन मेरी सिफारिश (2) के बजाय (1) पर ध्यान केंद्रित करने की होगी।

ध्यान दें कि हमारे पास मुश्किल से कोरएफएक्स बिल्डिंग-ऑन-लिनक्स और बिल्डिंग-ऑन-ओएसएक्स है, जैसे कि हमारा सीआई सिस्टम विंडोज़ पर उन प्लेटफॉर्म के लिए असेंबली बनाता है; इसके बाद यह परिणामी असेंबली को परीक्षणों को निष्पादित करने के लिए लक्ष्य प्लेटफॉर्म पर बंद कर देता है।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें।

हां, मैं किसी भी तरह से असहमत नहीं हूं... Linux, OSX, और FreeBSD पर _build_ corefx में सक्षम होना महत्वपूर्ण है। मैं केवल यह सुझाव दे रहा हूं कि प्राथमिकता के नजरिए से यह वास्तव में Linux, OSX और FreeBSD पर _run_ corefx में सक्षम होना अधिक महत्वपूर्ण है। :विंक: यदि दोनों पर समानांतर में काम किया जा सकता है, तो और भी अच्छा।

@घुंटले ,
सुपर होगा: कूल: अगर हमारे पास मार्कडाउन टास्क चेकलिस्ट है जो यह बताती है कि क्या बचा है:

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

के रूप में प्रस्तुत करता है:

• [ ] कार्य 1
• [] कार्य 2
• [] कार्य 3

यह शायद दूसरों को उन करतबों को हासिल करने के लिए प्रोत्साहित करेगा और फ्रीबीएसडी समर्थन अपेक्षा से जल्दी ही उतरेगा! धूप का चश्मा:

मेरी जानकारी के लिए FreeBSD समर्थन के लिए CoreFX में निम्नलिखित कार्य आवश्यक हैं:

• [x] बिल्ड टूल्स और स्क्रिप्ट्स के लिए फ्रीबीएसडी प्लेटफॉर्म का परिचय दें। ( @josteink और मेरे द्वारा किया गया, PRs dotnet/corefx#2021 मर्ज किया गया, dotnet/corefx#2030 मर्ज किया गया)

13 असेंबली अपने आप संकलित नहीं होती हैं और उन्हें फ्रीबीएसडी विशिष्ट परिवर्तनों की आवश्यकता होती है। अधिकतर इंटरऑप टुकड़े जो पहले से ही लिनक्स/ओएस एक्स के लिए मौजूद हैं (बिल्ड आउटपुट में घटना के क्रम में):

• [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, PR dotnet/corefx#3257)
• [x] System.IO.Compression.ZipFile (किया गया, PR dotnet/corefx#2041 मर्ज किया गया)
• [x] System.IO.FileSystem.DriveInfo (चर्चा dotnet/corefx#2526, PR dotnet/corefx#2606)
• [x] System.IO.FileSystem.Watcher (चर्चा dotnet/corefx#2046, PR dotnet/corefx#3257)
• [x] System.IO.FileSystem (किया गया, PR dotnet/corefx#2049 मर्ज किया गया)
• [x] System.IO.MemoryMappedFiles (चर्चा dotnet/corefx#2527, PR dotnet/corefx#3143)
• [x] System.IO.Pipes (चर्चा dotnet/corefx#2528, PR dotnet/corefx#2974)
• [x] System.Net.NameResolution (चर्चा dotnet/corefx#2988, PR 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 (डॉटनेट/कोरएफएक्स#1999 द्वारा अवरुद्ध)
• [x] System.Runtime.InteropServices.RuntimInformation (किया गया, PR dotnet/corefx#2068 मर्ज किया गया)

मैं खोले और मर्ज किए गए पीआर के आधार पर उस सूची को अपडेट करने का प्रयास करूंगा।

FYI करें: PR dotnet/corefx#2039 मर्ज किया गया

बस यहाँ वक्र से आगे रहने की कोशिश कर रहा है... हम System.IO.FileSystem.Watcher को कैसे लागू करने की योजना बना रहे हैं?

Iirc FreeBSD के पास कोई inotify जैसे कि Linux और Windows करता है (यही कारण है कि पिछली बार जब मैंने जाँच की तो कोई ड्रॉपबॉक्स नहीं था)। क्या यह हमारे रास्ते में आने वाली परेशानी का एक संभावित स्रोत होगा? या क्या किसी के पास इस बारे में कोई विचार है कि इसके आसपास कैसे काम किया जाए?

मेरा सुझाव है कि हम इस समय इसे रोक दें और एक PlatformNotSupportedException फेंक दें जैसा कि स्टीफन टुब ने दूसरे विषय में सुझाया था (https://github.com/dotnet/corefx/pull/2021#issuecomment-111602342)। तब हमारे पास कम से कम असेंबली का एक पूरा सेट होता है और हम आगे के कदमों को अवरुद्ध किए बिना उस विशेष मुद्दे पर काम करना जारी रख सकते हैं।

क्या आप इसके लिए एक अलग मुद्दा खोलने पर विचार करेंगे?

आइए System.IO.FileSystem.Watcher चर्चाओं को dotnet/corefx#2046 . पर ले जाएं

दोस्तों क्या System.Diagnostics.Process लिए ऐसा कोई अवरोधक है?

@ jasonwilliams200OK ने आज सुबह S.RT.I.RI में FreeBSD को जोड़ा, जिसे मर्ज कर दिया गया था, लेकिन CheckPlatformTests भीतर FreeBSD परीक्षणों को dotnet/buildtools अपडेट होने तक बैक आउट करना पड़ा।

• [ ] फ्रीबीएसडी को सपोर्ट करने के लिए बिल्ड टूल्स को अपडेट करें -
• [ ] CheckPlatformTests पर [Fact,PlatformSpecific(PlatformID.FreeBSD)] परीक्षण दोबारा लागू करें - https://github.com/dotnet/corefx/pull/2068#discussion_r32570244 और https://github.com/dotnet/corefx/pull/2068#discussion_r32570244 देखें।
• [ ] public static OSPlatform FreeBSD को https://github.com/dotnet/corefx/pull/2068 में जोड़ें

@ jasonwilliams200OK कल रात System.Diagnostics.Process बारे में कुछ चर्चा हुई थी जिसे https://github.com/dotnet/corefx/issues/2070 में औपचारिक रूप दिया गया है।

@ घुंटले , धन्यवाद। मैं वास्तव में उन संदेशों को पढ़ता हूं। System.Diagnostics.Process एक मुश्किल है। AFAIK, io.js टीम को FreeBSD प्रक्रिया प्रबंधन के साथ समान चुनौतियां थीं। मोनो टीम ने शायद इसे भुनाया है , तो उम्मीद है कि

System.IO.FileSystem.DriveInfo

जैसा कि गटर में चर्चा की गई है, इसके लिए मैंने 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
$

तो ऐसा लगता है कि यह वही करता है जो हमें चाहिए। सवाल यह है कि क्या हमें परिणामों पर किसी प्रकार की छानबीन करनी चाहिए?

.NET की विंडोज़ दुनिया से आने वाले DriveInfo ऑब्जेक्ट के "इरादे" को देखते हुए, यह अक्सर फाइलों को संग्रहीत करने या पुनर्प्राप्त करने के लिए उपलब्ध स्थानों की गणना करने के लिए किया गया है ( C: , D: , आदि)। लेकिन यूनिक्स पदानुक्रमित फाइल-सिस्टम का उपयोग करते समय, / लौटाना उन जरूरतों को पूरा करने के लिए पर्याप्त होगा।

तो हमें क्या लौटना चाहिए? क्या उपयोगी होगा? इसे उपयोगी भी मानना ​​चाहिए या नहीं?

लिनक्स-संस्करण सब कुछ डंप करता है, सिवाय चीजों को अनदेखा करने के लिए:

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 पर आधारित, मुझे लगता है कि हमें इसके साथ आने के लिए

मेरे पास OSX पर चलने वाला एक संस्करण है जो प्रत्येक माउंट पॉइंट के बारे में जानकारी प्राप्त करने के लिए getmntinfo और statfs का उपयोग करता है, जो कि विंडोज ड्राइव अवधारणा से सबसे तार्किक मैपिंग जैसा लगता है। मैं दोबारा जांच करूंगा कि ओएसएक्स पर फ़ंक्शन और संरचना परिभाषाएं फ्रीबीएसडी परिभाषाओं से मेल खाती हैं और यदि हां, तो ओएसएक्स के लिए मेरी प्रतिबद्धता बीएसडी के लिए भी काम करेगी।

मैं आपको अपने पीआर में जोड़ना सुनिश्चित करूंगा @josteink

बढ़िया है। आगे बढ़ने के लिए धन्यवाद और फ्रीबीएसडी को भी कुछ प्यार देने के लिए धन्यवाद।

मैंने इन कार्यों के लिए कुछ बुनियादी पिनवोक पर ध्यान दिया, और ऐसा लगता है कि हमें सभी मार्शलिंग और रूपांतरण स्वयं करने की आवश्यकता है, इसलिए यदि किसी और ने पहले से ही प्रयास किया है, तो मैं कौन नहीं कहने वाला हूं? ;)

कोई बात नहीं...ऐसा लगता है कि मुख्य अंतर संरचना घोषणाओं के साथ था; चूंकि हम भविष्य में इसे और अधिक हिट करेंगे, मैं कुछ रिफैक्टरिंग कर रहा हूं जो हमें बहुत सारे पिनवोक हस्ताक्षर साझा करने की अनुमति देगा। मैं अपने पीआर में एक बड़ा विवरण जोड़ूंगा (आज या कल, परीक्षण कैसे चलता है इसके आधार पर) लेकिन मैंने मूल रूप से फ्रीबीएसडी के लिए पिनवोक हस्ताक्षर और संरचना हस्ताक्षर जोड़े (हेडर के आधार पर मुझे ऑनलाइन मिला) और यह संकलित करता है। मैंने मैक पर इसका परीक्षण किया है, इसलिए यह _ चाहिए_ (सिद्धांत रूप में ...) फ्रीबीएसडी पर काम करता है क्योंकि यह सिर्फ एक संरचना घोषणा परिवर्तन है, लेकिन आपका लाभ भिन्न हो सकता है :)। यदि ऐसा नहीं होता है, तो आपके पास ड्राइवइन्फो क्लास और पिनवोक 99% रास्ते होंगे और बस फ्रीबीएसडी बारीकियों के आधार पर कुछ ट्विकिंग की आवश्यकता होगी।

बहुत बढ़िया खबर @sokket। मैंने आपको उस मशीन पर एक खाता बनाया है जिसे पोर्ट-टीम विकास के लिए उपयोग करती है, यह यूरोपीय आधारित है लेकिन यह हमेशा चालू रहता है और इसमें मेमोरी और प्रोसेसिंग पावर का ढेर होता है। उम्मीद है कि यह w/FreeBSD काम करते समय कुछ घर्षण को दूर करने और दूर करने में मदद करेगा।

# ssh [email protected]

पासवर्ड प्रमाणीकरण अक्षम है, अपनी किसी एक कुंजी का उपयोग

@josteink यह भी देखें: https://github.com/dotnet/corefx/issues/815 (मैक/फ्रीबीएसडी के लिए System.IO.FileSystem.DriveInfo)

क्या कोई अपडेट हैं? क्या किसी ने शेष असेंबलियों को फ्रीबीएसडी पर लागू किया?

मैं अपने नए बच्चे को देखने में व्यस्त हूं, मेरे पास कहीं भी कोडिंग के लिए समय नहीं है।

मुझे संदेह है कि इस तरह के मुद्दे निष्क्रिय पड़े हैं और मुझे लगता है कि यह कुछ हद तक इसकी पुष्टि करता है।

उन विधानसभाओं के लिए जो अभी भी लागू नहीं हुई हैं, मैंने ऊपर दी गई सूची में "कैसे लागू करें" -मुद्दे को जोड़ा। मुझे उम्मीद है कि इससे इन शेष विधानसभाओं को लागू करने के प्रयास में समन्वय करने में मदद मिलेगी।

मुझे यह स्वीकार करना होगा कि हमने क्या किया है और कहां किया है, इस पर नज़र रखने में मुझे कठिनाइयाँ हो रही थीं, इसलिए यह निश्चित रूप से एक अच्छा कदम है। बहुत बढ़िया :)

मैं इसे कहां ढूंढूं? शेष विधानसभाओं को प्राप्त करने के लिए आभारी होंगे
क्रियान्वित किया।

25/07/15 22:10 को, जान हेन्के ने लिखा:

उन विधानसभाओं के लिए जो अभी भी लागू नहीं हुई हैं, मैंने "कैसे" लिंक किया है
लागू करने के लिए"-उपरोक्त सूची में जारी करें। मुझे आशा है कि समन्वय में मदद मिलेगी
इन शेष विधानसभाओं को लागू करने का प्रयास।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/dotnet/corefx/issues/1626#issuecomment -124838781।

यह टिप्पणी यहाँ: https://github.com/dotnet/corefx/issues/1626#issuecomment -111800540

मैं अभी देशी शिम के समाप्त होने की प्रतीक्षा कर रहा हूं, क्योंकि इन विधानसभाओं को फ्रीबीएसडी पर काम करने के लिए अधिकांश काम इन पर लेना चाहिए।

@nguerrera बहुत अच्छा होगा यदि आप हमें प्रगति पर पोस्ट कर सकते हैं। :)

अद्यतन:
@janhenke ने पुष्टि की कि https://github.com/dotnet/corefx/pull/2974 विलय के साथ, System.IO.Pipes FreeBSD पर बनता है! धूप का चश्मा:

अद्यतन:
dotnet/corefx#2527 बंद, System.IO.MemoryMappedFiles फ्रीबीएसडी पर बनता है।
पुष्टि के लिए धन्यवाद @janhenke !

शिम दृष्टिकोण के लिए धन्यवाद, यह सुनिश्चित करने के लिए नीचे आता है कि शिम फ्रीबीएसडी पर संकलित है। शुक्र है कि इससे जीवन बहुत आसान हो जाता है। :)

dotnet/corefx#3257 हमें System.Diagnostic.Process और System.IO.FileSystem.Watcher दोनों को लाना चाहिए, जिससे केवल System.Net.NameResolution अनसुलझा रह जाए। (पीआर के विलय और फ्रीबीएसडी पर काम करने के बाद मैं उल्लिखित दो विधानसभाओं की जांच करूंगा)

dotnet/corefx#3471 को हमें System.Net.NameResolution लाना चाहिए और ऊपर दी गई सूची को पूरा करना चाहिए।

dotnet/corefx#3471 अभी मर्ज किया गया था :)

@sokket , अपडेट के लिए धन्यवाद। मैंने इस गाइड का उपयोग करके फ्रीबीएसडी पर मास्टर (f467911) बनाया: https://gist.github.com/jasonwilliams200OK/6efa7907e66275df2d24। वर्तमान अवरोधक https://github.com/dotnet/buildtools/issues/292 है, जो अपस्ट्रीम में तय है लेकिन अगले बिल्डटूल रोल-आउट की प्रतीक्षा कर रहा है। :)

अपडेट करें: डॉटनेट/बिल्डटूल # 292 के लिए फिक्स के साथ नए बिल्डटूल कोरएफएक्स मास्टर में उतरे हैं। बिल्डटूल से अगला स्टॉपर है https://github.com/dotnet/buildtools/issues/300 : परीक्षण चलाने में सक्षम होने के लिए लापता ओएस विशिष्ट उपकरण।

@janhenke , आपने System.Diagnostics.Process (#2070) और System.IO.FileSystem.Watcher (#2046) को हो गया के रूप में चिह्नित किया है; लेकिन वे न तो लागू होते हैं और न ही वे फ्रीबीएसडी पर संकलित होते हैं। क्या आपने वास्तव में प्रबंधित कोड संकलित करके सूची को सत्यापित किया है?

60c78da3c918b0d256cc1f878de06d351dbe3342 ( msbuild.log देखें) के साथ मेरे हालिया अनुभव के आधार पर, निम्नलिखित असेंबली संकलित नहीं करते हैं:

• System.Diagnostics.Process
• System.Diagnostics.ProcessManager
• System.Diagnostics.ThreadInfo
• System.IO.FileSystemWatcher
• System.Net.SocketAddress _(ठीक है, यह हाल ही में जोड़ा गया था)_

जहाँ तक मुझे याद है मैंने संबंधित शिम संकलन को सत्यापित किया है। चूंकि प्रबंधित कोड फ्रीबीएसडी विशिष्ट कोड से मुक्त होना चाहिए। आप जिन शिमों का उल्लेख करते हैं, उन्हें ऊपर लिंक किए गए पीआर के साथ हटा दिया जाना चाहिए था।
लेकिन मैंने बीच में एक पूर्ण संकलन भी चलाया है। कम से कम System.Diagnostics.ThreadInfo और System.IO.FileSystemWatcher ने संकलन किया। तो कुछ तो वापस आ गया होगा।

आप जिन शिमों का उल्लेख करते हैं, उन्हें ऊपर लिंक किए गए पीआर के साथ हटा दिया जाना चाहिए था।

दरअसल, पीआर https://github.com/dotnet/corefx/pull/3257 शिम से संबंधित नहीं है। प्रबंधित परियोजनाओं (पुराने दृष्टिकोण) के भीतर अभी भी कुछ पीएएल कोड हैं, इसलिए पूरी तरह से सुनिश्चित होने के लिए प्रबंधित असेंबली बनाना आवश्यक है।

दरअसल, PR dotnet/corefx#3257 शिम से संबंधित नहीं है।

मैं असहमत हूं। यह P/Invoke कोड को System.Native shim में रिफैक्टरिंग कर रहा है। जैसा कि मैंने ऊपर संपादित किया है, मैं बीच में संकलित कम से कम कुछ विधानसभाओं को याद कर रहा हूं।

मैं असहमत हूं

https://github.com/dotnet/corefx/pull/3257/files : .Unix.cs और .Linux.cs लिए System.Diagnostics. के उदाहरण देखें। ध्यान दें कि .OSX.cs अछूता है।

यह P/Invoke कोड को सिस्टम में रिफैक्टरिंग कर रहा है। नेटिव शिम

हां यह System.Native तहत कुछ सामान्य सहायकों को दोबारा प्रतिक्रिया देता है, लेकिन System.Diagnostics.* एट अल नहीं।

यहां तक ​​​​कि जब ये असेंबली केवल P/System.* libs का आह्वान कर रहे हैं, तब भी उनमें से कुछ के लिए FreeBSD कार्य की आवश्यकता हो सकती है, जैसे System.Diagnostics.Process और System.IO.FileSystem.Watcher। वे लिनक्स और ओएस एक्स के लिए विशिष्ट कार्यक्षमता का उपयोग कर रहे हैं, और हम मूल शिम के पीछे अमूर्त करने की कोशिश करने की योजना नहीं बनाते हैं। शिम का लक्ष्य यूनिक्स के लिए एक प्रबंधित बाइनरी के साथ समाप्त नहीं होना है, हालांकि यह काम से आने पर एक बहुत अच्छी संपत्ति है; प्राथमिक लक्ष्य एबीआई मतभेदों से बचना है जो नाजुकता का कारण बनते हैं। मुझे उम्मीद है कि कम से कम कुछ असेंबली में लिनक्स/ओएस एक्स विशिष्ट बाइनरी जारी रहेगी, जहां एक फ्रीबीएसडी बाइनरी की भी आवश्यकता होगी।

FYI करें, System.Diagnostics.ProcessManager नाम की कोई कोरएफएक्स असेंबली नहीं है,
System.Diagnostics.ThreadInfo,
System.IO.FileSystemWatcher, या
System.Net.SocketAddress। वे अन्य विधानसभाओं में प्रकार हैं।

मुझे उम्मीद है कि कम से कम कुछ असेंबली में लिनक्स/ओएस एक्स विशिष्ट बाइनरी जारी रहेगी, जहां एक फ्रीबीएसडी बाइनरी की भी आवश्यकता होगी।

क्या इसका मतलब यह है कि जब भी सोलारिस और गैर-ग्लिबैक (musl और μlibc) लिनक्स को लक्षित करने वाले अल्पाइन समर्थन आएंगे, तो उनके पास अलग-अलग बायनेरिज़ होंगे? और फिर विभिन्न आर्किटेक्चर एआरएम, एमआईपीएस, आरआईएससी, एसपीएआरसी इत्यादि को अलग-अलग स्तर की अलगाव की आवश्यकता होगी?

क्या उन्हें POSIX इंटरफ़ेस / sys- कॉल में जितना संभव हो सके एकाग्र करना और एक ही बाइनरी में उपयोग किए जाने वाले कॉन्फिग (सीएमके के माध्यम से) का उपयोग करके अंतर का पता लगाना (जब तक कि यह आकार/प्रदर्शन को प्रभावित नहीं कर रहा है) असेंबली महत्वपूर्ण रूप से)? जैसा कि मैंने इसे समझ लिया है, System.Native.so बाइनरी में अन्य विशिष्ट System.*.Native.so लिए सामान्य सहायक है जो अलग-अलग चिंताओं के सिद्धांत अनुपालन के लिए पर्याप्त लगता है। लेकिन अगर यह System.Net.Http.FreeBSD.ARM.Native.so या System.Net.Http.Solaris.SPARC.so , तो यह "बहुत अधिक चलने वाले हिस्सों" आदि के साथ काफी अप्रबंधनीय होगा।

नाम की कोई कोरएफएक्स असेंबली नहीं है

अच्छी बात। मैं वास्तव में एमएसबिल्ड लॉग और .OSX.cs और .Linux.cs फाइलों की संख्या में विफलताओं के उदाहरणों से जा रहा था। :मुस्कुराओ:

क्या उन्हें यथासंभव POSIX इंटरफ़ेस / sys- कॉल में परिवर्तित करने का कोई मतलब नहीं होगा

हम कर। आप POSIX के माध्यम से फ़ाइल को अच्छी तरह से देखने का प्रस्ताव कैसे देते हैं? आप कैसे प्रस्तावित करते हैं कि हम POSIX के माध्यम से गणना प्रक्रिया को अच्छी तरह से करते हैं?

लेकिन अगर यह System.Net.Http.FreeBSD.ARM.Native.so या System.Net.Http.Solaris.SPARC.so में तब्दील हो जाता है, तो यह "बहुत अधिक चलती भागों" आदि के साथ काफी असहनीय होगा।

मैं यह नहीं समझता। मूल .so फ़ाइलों का संपूर्ण बिंदु यह है कि आपको प्रत्येक लक्ष्य प्लेटफ़ॉर्म के लिए अलग-अलग मूल बायनेरिज़ मिलते हैं, लेकिन उनका नाम System.Whatever.Platform.ext, बस System.Whatever.ext; जो संकलक को समान सामान्य तर्क लेने और उस प्लेटफ़ॉर्म के लिए विशिष्ट परिभाषाओं के साथ इसका उपयोग करने की अनुमति देता है। यह केवल तभी काम करता है जब प्रत्येक प्लेटफॉर्म पर समान प्रतीक मौजूद हों; संकलक जादुई रूप से inotify का उपयोग करने के लिए लिखे गए कोड को नहीं लेता है और इसे किसी अन्य सिस्टम से फ़ाइल देखने वाले इंटरफ़ेस के साथ काम करने की अनुमति देता है। सामान्य तौर पर हमने मानकीकृत एपीआई का उपयोग करने के लिए कड़ी मेहनत की है जहां यह समझ में आता है, लेकिन उन जगहों के लिए जहां ऐसे एपीआई मौजूद नहीं हैं या अच्छी तरह से मानकीकृत नहीं हैं या जहां बेहतर प्लेटफॉर्म-विशिष्ट समाधान हैं, हमने बेहतर प्लेटफॉर्म का उपयोग किया है- विशिष्ट समाधान, उदाहरण के लिए, लिनक्स पर प्रक्रिया गणना के लिए procfs का उपयोग करना, लिनक्स पर फाइल सिस्टम को देखने के लिए इनोटिफाई का उपयोग करना, आदि। क्या ऐसा प्लेटफॉर्म-विशिष्ट तर्क प्रबंधित या देशी कोड में रहता है, वास्तव में आसानी से पोर्ट करने से कोई फर्क नहीं पड़ता- अतिरिक्त-प्लेटफ़ॉर्म परिप्रेक्ष्य, जैसे कि जब वे नए प्लेटफ़ॉर्म आते हैं, यदि मौजूदा एपीआई काम करते हैं, तो मौजूदा समाधान भी करता है, और यदि ऐसा नहीं होता है, तो आपको उस प्लेटफ़ॉर्म के लिए एक नया समाधान लिखना होगा। और इसलिए हमने प्रबंधित कोड में जितना संभव हो उतना करने की कोशिश की है, केवल 1:1 शिम के लिए देशी का उपयोग करते हुए जो उस प्रबंधित कोड को और अधिक पोर्टेबल बनाते हैं जहां लक्ष्य एपीआई पोर्टेबल होते हैं। हमने छोटे विवरणों पर प्रकाश डालने के लिए मूल कोड में #ifdefs का उपयोग किया है, जहां यह एपीआई किस प्लेटफॉर्म पर किसी अन्य प्लेटफॉर्म पर उस एपीआई के काफी करीब है, लेकिन यह पूरी तरह से अलग होने के कारण संपूर्ण समाधानों तक विस्तारित नहीं होता है; उस समय अमूर्त प्रबंधित एपीआई बन जाता है और हम प्रत्येक सिस्टम के लिए एक अलग प्रबंधित कार्यान्वयन करते हैं।

यदि फ्रीबीएसडी इनोटिफाई को लिनक्स के रूप में उजागर करता है या यदि यह ओएस एक्स के रूप में इवेंटस्ट्रीम को उजागर करता है, तो जब वे ओएस एपीआई शिम के पीछे होते हैं, तो शिम को आसानी से फ्रीबीएसडी के साथ काम करने के लिए बनाया जा सकता है, और उसी प्रबंधित बाइनरी का उपयोग फ्रीबीएसडी पर किया जा सकता है। यदि फ्रीबीएसडी ऐसे एपीआई को उजागर नहीं करता है, तो आपको कुछ फाइल देखने के समाधान के साथ System.IO.FileSystem.Watcher का एक कस्टम कार्यान्वयन लिखना होगा जो फ्रीबीएसडी पर उपलब्ध है। System.Diagnostics.Process के लिए समान टिप्पणियाँ। फ़ाइल देखने के लिए कोड शिम में है या नहीं, इसका उस पर बहुत कम प्रभाव पड़ता है।

इस तरह के सभी देशी एपीआई को अंततः शिम के पीछे ले जाने की योजना है। लेकिन वे प्राथमिकता से बहुत दूर हैं, क्योंकि वे बहुत पोर्टेबल नहीं हैं, और इसलिए आपने हमें libc से एपीआई से शुरू करते हुए देखा है जो हर जगह उजागर (या माना जाता है)।

आप POSIX के माध्यम से फ़ाइल को अच्छी तरह से देखने का प्रस्ताव कैसे देते हैं?

हम यह सब POSIX नहीं कर सकते, क्योंकि inotify Linux विशिष्ट है। फ्रीबीएसडी/ओएसएक्स एक अलग कार्यान्वयन प्रदान करता है।

प्रस्ताव:

देशी बायनेरिज़ वितरण के दृष्टिकोण से, प्रत्येक 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" एक साझा यूनिक्स प्रबंधित बाइनरी में तर्क से खपत किए गए 1:1 फ़ंक्शन नेटिव-शिम किए गए हैं
• "sightly_diverged_function" एक साझा यूनिक्स प्रबंधित बाइनरी में तर्क से खपत कुछ देशी #ifdefs के साथ लगभग 1:1 कार्यों को मूल रूप से शिम किया गया है
• "दर्दनाक_डाइवरेज_वॉच_फंक्शन" प्लेटफॉर्म-विशिष्ट प्रबंधित बायनेरिज़ में तर्क से खपत किए गए 1:1 कार्यों को मूल रूप से शिम किया जाएगा / किया जाएगा

वास्तविक अंतर यह है कि क्या "दर्द से अलग" तर्क को लागू करने वाला कोड सी # या सी ++ में किया जाता है, और हमने सी # चुना है और यह पहले से ही सी # में लागू हो चुका है। मैंने इस बात के लिए कोई सम्मोहक तर्क नहीं देखा है कि ऐसे मामलों में C++ में होने के लिए इसे फिर से लिखना एक अधिक सम्मोहक विकल्प क्यों होगा।

@ jasonwilliams200OK मोनो के आज के अपडेट के साथ मैं फिर से FreeBSD पर ही corefx बना रहा हूं। पिछली बार जब से मैंने इसे बनाया था, तब से बहुत सारे नए त्रुटि संदेश हैं।
मैं सोच रहा हूँ कि क्या Interop.Libc अंततः चला जाएगा?

@stephentoub यह सब पैकेजिंग के लिए नीचे आता है। मूल भाग में सभी प्लेटफ़ॉर्म विशिष्ट कोड होने से सभी यूनिक्स जैसे प्लेटफ़ॉर्म के लिए एक प्रबंधित असेंबली होने का लाभ मिलता है।
इसके अलावा, मुझे दृढ़ता से लगता है कि हमें इन "प्लेटफ़ॉर्म पर निर्भर प्रबंधित कोड के लिए एक सामान्य कार्यान्वयन की आवश्यकता है। भले ही यह एक NotImplementedExcpetion फेंकता हो। इस तरह आप नए प्लेटफॉर्म पर बहुत आसान पोर्ट कर सकते हैं, अगर यह कम से कम सब कुछ तुरंत संकलित करता है। इसके अलावा यह देगा कम से कम एक असमर्थित मंच पर चलने का प्रयास करने का मौका।
आम तौर पर यह बहुत आसान होता है यदि आप कम से कम तुरंत सफलतापूर्वक संकलित कर सकते हैं।

@stephentoub , क्षमा करें, मैं C++ को C# के साथ मिला रहा था। अब मैं समझता हूं कि मूल परत केवल उन प्रवेश बिंदुओं (मूल libs funcitons या syscalls) को उजागर कर रही है और IO और प्रबंधित कोड को स्वच्छ कर रही है, जहां हम तय करते हैं कि कौन सी प्लेटफ़ॉर्म-विशिष्ट लिपटे उपयोगिता विधि/लिपटे सिस्कल का उपभोग किया जाना है। इसके अलावा, दोनों (मूल और प्रबंधित) स्तर ओएस-अज्ञेयवादी नहीं हो सकते हैं जहां गैर-पॉज़िक्स कार्यक्षमता का उपभोग किया जाना है।

@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 जिस्ट लिंक पोस्ट करेंगे।

इसके अलावा, मुझे दृढ़ता से लगता है कि हमें इन "प्लेटफ़ॉर्म निर्भर प्रबंधित कोड" के लिए एक सामान्य कार्यान्वयन की आवश्यकता है।

मैं सहमत हूं। आंशिक कक्षाओं के बजाय, हम शायद अमूर्त आधार वर्ग में सामान्य और अधिकतर सामान्य आभासी विधियों के साथ विरासत का उपयोग कर सकते हैं और जहां आवश्यक हो "ज्यादातर सामान्य/आंशिक रूप से अलग" के लिए ओवरराइड कर सकते हैं। फिर अमूर्त विधियों को लागू करें जो प्रत्येक ओएस के लिए बिल्कुल अलग हैं। इस दृष्टिकोण के साथ IMO, यदि विशेषज्ञता/सामान्यीकरण DRY'ing खो रहा है, तो हम कर्मचारी बहु-डिग्री वंशानुक्रम वंश कर सकते हैं। लेकिन पिछली बार जब मैंने जाँच की थी, CoreFX में माता-पिता-बाल संघ पर आंशिक कक्षाओं को प्राथमिकता दी गई थी (किसी कारण से मुझे याद नहीं है)। :)

यहाँ 2d36889 प्रतिबद्ध करने के लिए msbuild.log है:

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

/सीसी: @akoeplinger

@ jasonwilliams200OK इतना जटिल क्यों है। इसके लिए प्रोजेक्ट फाइलों में "अगर विंडोज, लिनक्स, ओएस एक्स नहीं है" की जरूरत है। तो या तो बिल्ड या जेनेरिक फाइलों में फाइलों का एक मंच विशिष्ट सेट शामिल करें।

मुझे नहीं लगता कि कुछ असेंबली फ्रीबीएसडी के लिए निर्माण/काम नहीं कर सकती हैं, फिर भी उनमें से बाकी के परीक्षण के लिए एक प्रमुख अवरोधक होना चाहिए। हमें शायद इसे सिर्फ इसलिए बनाना चाहिए ताकि लंबित काम (फाइलसिस्टम वॉचर, प्रोसेस, नेटवर्किंग) वाले लोग फ्रीबीएसडी पर बिल्ड और टेस्ट रन में छोड़ दिए जाएं। फिर हम पहले से ही काम कर रहे प्रतिगमन को रोकने के लिए एक प्रक्रिया रखते हुए उन्हें व्यक्तिगत रूप से ला सकते हैं।

मुझे नहीं लगता कि कुछ असेंबली फ्रीबीएसडी के लिए निर्माण/काम नहीं कर सकती हैं, फिर भी उनमें से बाकी के परीक्षण के लिए एक प्रमुख अवरोधक होना चाहिए

माना

हमें शायद इसे सिर्फ इसलिए बनाना चाहिए ताकि लंबित काम (फाइलसिस्टम वॉचर, प्रोसेस, नेटवर्किंग) वाले लोग फ्रीबीएसडी पर बिल्ड और टेस्ट रन में छोड़ दिए जाएं।

या जैसा कि @janhenke ने सुझाव दिया था, बस उन्हें बनाने की अनुमति दें, या तो उन फ़ाइलों के साथ स्टबिंग करके जो PlatformNotSupported को फेंक देती हैं, या केवल FreeBSD को काम करने वाले मामलों में से एक में मैप करके, उदाहरण के लिए यदि FreeBSD चुना जाता है, तो बस Linux का निर्माण करें ( यह काम नहीं करेगा, लेकिन यह निर्माण करेगा)।

@ellismg हाल के परिवर्तनों (#3684) के साथ, मैं पिछली विधि को सरल बनाकर परीक्षण चलाने में सक्षम हूं (https://github.com/dotnet/coreclr/issues/1633#issuecomment-143669303):

• https://gist.github.com/jasonwilliams200OK/6efa7907e66275df2d24 के बाद (विशेष रूप से मूल शिम को अलग से बनाने का चरण _after_ स्थिति 1 के साथ बिल्ड.श से बाहर निकलें), CoreCLR कलाकृतियों को डाउनलोड करें: 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 ।

(विंडोज मशीन से कुछ भी आवश्यक नहीं)

• परीक्षण चलाया:

./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 परीक्षण विफल

मुझे नहीं लगता कि कुछ असेंबली फ्रीबीएसडी के लिए निर्माण/काम नहीं कर सकती हैं, फिर भी उनमें से बाकी के परीक्षण के लिए एक प्रमुख अवरोधक होना चाहिए।

मुझे इससे सहमत होना है। परीक्षण शुरू करने से पहले सब कुछ पूरा होने की प्रतीक्षा करने के बजाय, हमने जो काम किया है, उसकी QAing शुरू करना बेहतर है।

यह कहता है: 40 परीक्षण विफल रहे

कितने में से 40? हम किस बॉलपार्क में हैं? :)

कितने में से 40? हम किस बॉलपार्क में हैं? :)

मुझे भी पीटता है। परीक्षण परीक्षण असेंबली (प्रबंधित डीएलएस) से बाहर हो रहे हैं और परीक्षणों की कुल संख्या दिखाई नहीं दे रही है।

स्क्रिप्ट अंत में उत्पन्न होने वाली संख्या परीक्षण असेंबली की संख्या है जो विफल रही। xUnit को उन परीक्षणों की संख्या लिखनी चाहिए जो प्रति असेंबली में विफल होने के कारण इसे चलाने के हिस्से के रूप में stdout में विफल रहे। संख्याएं एक्सएमएल फाइलों में भी होनी चाहिए जो प्रत्येक टेस्ट असेंबली फ़ोल्डर में उत्पन्न होती हैं।

यह रनटाइम भी हो सकता है बस दुर्घटनाग्रस्त हो रहा है और उस स्थिति में प्रति टेस्ट असेंबली में लॉग नहीं हो सकते हैं।

@ jasonwilliams200OK क्या आप जानते हैं कि असेंबली साइनिंग के मुद्दे पर कोई प्रगति हुई है या नहीं? मैं उबंटू पर एक ही चीज़ मार रहा हूं। अगर कोई इस पर काम नहीं कर रहा है, तो शायद हमें इसके लिए एक अलग मुद्दा खोलना चाहिए।

@naamunds , जो https://github.com/dotnet/corefx/issues/3739 के हिस्से के रूप में CoreFX मास्टर पर तय किया गया है

अपडेट - आज मैंने फ्रीबीएसडी पर परीक्षण चलाए, उनमें से हजारों पास हो रहे थे और फिर कुछ सिस्टम की स्पष्ट कमी के कारण असफल हो रहे थे। डायग्नोस्टिक्स। प्रक्रिया और दोस्तों स्नफू। ~ 40 मिनट के सफल निष्पादन के बाद, यह System.IO.FileSystem परीक्षणों पर लटका रहा (लगभग ~ 15 मिनट के लिए मैंने Ctrl + C को समाप्त करने के लिए दबाया)।

@ jasonwilliams200OK आपने freebsd के तहत corefx को संकलित करने का प्रबंधन कैसे किया? मैं gssapi . के बारे में त्रुटियों पर फंस गया हूँ

@sec , इन नोट्स को बनाते समय: https://gist.github.com/jasonwilliams200OK/6efa7907e66275df2d24 , CoreFX द्वारा GSSAPI की आवश्यकता नहीं थी। हालाँकि, ऐसा लगता है कि pkg को हाल ही में FreeBSD में पोर्ट किया गया है: http://www.freshports.org/security/p5-GSSAPI। आप pkg upgrade pkg && pkg update && pkg install p5-GSSAPI आज़माना चाह सकते हैं।

@ jasonwilliams200OK , मुझे पहले ही यह मिल गया है (यह पर्ल एक्सटेंशन है। btw।) समस्या गायब थी gssapi_ext.h। चाल "पीकेजी इंस्टॉल krb5" करना था - अब देशी संकलित।
मैंने उन्हें coreclr रनटाइम में कॉपी किया है, लेकिन फिर भी ASP.NET Core ऐप नहीं चला सकता :) लड़ाई तब चलती है।

इस कार्य की वर्तमान स्थिति क्या है? क्या @janhenke की सूची पूर्ण और सटीक है? क्या वे सभी कार्य किए जा रहे हैं, जिन्हें करने की आवश्यकता है? तो इसे बंद कर देना चाहिए, है ना?

यदि हां, तो हमारे पास अभी भी यह कार्य क्यों है? https://github.com/dotnet/corefx/issues/2070

यदि अभी भी काम करना बाकी है, तो क्या वर्तमान स्थिति के आधार पर एक नया मुद्दा दर्ज किया जाना चाहिए?

मुझे लगता है कि इसकी भी जरूरत है - dotnet/corefx#2046

क्या वर्तमान स्थिति के आधार पर एक नया मुद्दा पंजीकृत किया जाना चाहिए?

हां: +1:

हमने @RussellHaley (FreeBSD समुदाय से) और @wfurt (.NET कोर टीम से) के साथ FreeBSD के लिए समुदाय-संचालित पोर्ट पर चर्चा की, जिन्होंने दोनों ने काम में रुचि व्यक्त की।
यहां एक योजना प्रस्ताव है जिसे हमने एक साथ रखा है (प्रतिक्रिया/सुझावों का स्वागत है):

1. CoreCLR और CoreFX रेपो में बायनेरिज़ का निर्माण FreeBSD को लक्षित करना - हैक्स का उपयोग करना ठीक है
   
   
   
   • समानांतर करना मुश्किल है, @wfurt उस पर काम करेगा
   
   
   • बिल्ड अन्य प्लेटफॉर्म (मैक, लिनक्स) से फ्रीबीएसडी को लक्षित करने वाले बिल्ड का मिश्रण हो सकता है
   
   
   • फ्रीबीएसडी-विशिष्ट बग फिक्स के साथ बिल्ड को पुन: पेश करने के लिए हमें दस्तावेज चरणों (फ्रीबीएसडी विकी पर) की आवश्यकता होगी
   
   
2. CoreCLR परीक्षण चलाएँ और स्थिर करें (corerun का उपयोग करके)
   
   
   
   • टेस्ट दूसरे प्लेटफॉर्म पर बनाए जा सकते हैं
   
   
   • लक्ष्य: रनटाइम की बुनियादी गुणवत्ता प्रदान करता है
   
   
3. CoreFX परीक्षण चलाएँ और स्थिर करें (corerun का उपयोग करके)
   
   
   
   • टेस्ट दूसरे प्लेटफॉर्म पर बनाए जा सकते हैं
   
   
   • ध्यान दें कि इसके लिए xunit की आवश्यकता है। हमारा मानना ​​है कि, हमारे पिछले पोर्टिंग अनुभव के आधार पर, एक बार [2] हो जाने के बाद, xunit बस काम करेगा।
   
   
   • यह सिद्धांत रूप में [2] के समानांतर हो सकता है - इसके लिए xunit को शॉर्टकट करने की आवश्यकता हो सकती है (उदाहरण के लिए किसी अन्य प्लेटफॉर्म पर स्थिर निष्पादन नुस्खा उत्पन्न करना)
   
   
4. फ्रीबीएसडी पर पूर्ण स्टैक बिल्ड ([1]-[3] से बूटस्ट्रैपर के रूप में कोररन का उपयोग करके)
   
   
   
   • बूस्टरैपिंग पर काम करने के लिए हमें सभी टूल्स (nuget, msbuild, roslyn) की आवश्यकता होगी .NET Core
   
   
5. इंस्टालर (फ्रीबीएसडी पोर्ट)
   
   
   
   • पहला चरण: नगेट फ़ीड से उत्पाद बायनेरिज़ का उपयोग करना
   
   
   • दूसरा चरण: स्रोत से उत्पाद बनाएं (स्रोत प्रयास से निर्माण पर अवरुद्ध)
   
   
   • डिज़ाइन पर FreeBSD समुदाय विशेषज्ञता और मार्गदर्शन की आवश्यकता है
   
   
   • नोट: हम FreeBSD पैकेज को आधिकारिक .NET कोर डाउनलोड पेजों से भी समुदाय-समर्थन पैकेज के रूप में लिंक कर सकते हैं
   
   
6. फ्रीबीएसडी पर नियमित निर्माण और परीक्षण चलता है
   
   
   
   • लक्ष्य: सुनिश्चित करें कि फ्रीबीएसडी को तोड़ने वाले .NET कोर रेपो में परिवर्तन जल्दी ज्ञात हैं
   
   
   • डिजाइन की जरूरत
   
   
   • डिज़ाइन पर FreeBSD समुदाय विशेषज्ञता और मार्गदर्शन की आवश्यकता है
   
   

संचालन सिद्धांत:

• [2]-[4] में परिवर्तन मुख्य रूप से CoreCLR/CoreFX रेपो में किया जाना चाहिए (CLA हस्ताक्षर आवश्यकताओं के कारण, .NET कोर टीम के विशेषज्ञों/सदस्यों से कोड समीक्षा आदि)
• हम इस मुद्दे पर उच्च स्तरीय कार्य को ट्रैक करेंगे। विशिष्ट बग अलग मुद्दों के रूप में दायर किए जाएंगे।

अगर किसी को मदद करने में दिलचस्पी है, तो कृपया हमें यहां बताएं। एक बार जब हम [1] के साथ काफी दूर हो जाते हैं तो हम ऊपर [2] और [3] से काम की वस्तुओं को आसानी से वितरित कर सकते हैं।

प्रस्ताव का नवीनतम संस्करण इस अंक के शीर्ष पद पर है।

फ्रीबीएसडी -मोनो सूची ( यह धागा ) में रुचि व्यक्त करने वाले अधिक लोगों को टैग करना: @smortex @radovanovic @ इको-8-ईआरए

बीटीडब्ल्यू: मुझे मैथ्यू प्रीवोट गिटहब खाता नहीं मिल रहा है - [अद्यतन] https://github.com/dotnet/corefx/issues/1626#issuecomment -330348424: @mprevot में मिला

नेटबीएसडी के लिए हम मजबूत पॉज़िक्स म्यूटेक्स को याद करते हैं, यह एकमात्र विशेषता है जो अभी भी नामित रोबस म्यूटेक्स का उत्पादन करने के लिए गायब है। अब हम एलएलडीबी/नेटबीएसडी के साथ प्रबंधित कोड विफलताओं को डीबग कर सकते हैं .. यह कोर फाइलों के साथ ठीक काम करता है। मेरे पिछले प्रयासों में हम एलएलडीबी में इस सुविधा की कमी पर मर गए (मैंने इस डीबगर को .NET के लिए पोर्ट करना शुरू कर दिया)।

बेहतर फ्रीबीएसडी सपोर्ट होने से काफी मदद मिलेगी।

अतीत में हाइपरव गेस्ट सपोर्ट की कमी के साथ सीआई मशीनों के लिए नेटबीएसडी बिल्डबॉट संलग्न करने और पैच सत्यापित करने में भी समस्याएं थीं ... इसके लिए मुझे एमएस से मदद की आवश्यकता हो सकती है। मुझे उम्मीद है कि इसे चलाने के लिए आवश्यक मालिकाना सॉफ्टवेयर है, जो मेरे पास नहीं है ... मुझे काम करने के लिए एक डेवलपर मिल सकता है यदि नेटबीएसडी फाउंडेशन और माइक्रोसॉफ्ट के बीच संयुक्त हित (निवेश) होगा।

हम "मजबूत पॉज़िक्स म्यूटेक्स" को कहाँ याद करते हैं? क्या यह .NET कोर पाल का हिस्सा है?

आप किस सीआई सिस्टम का जिक्र कर रहे हैं? यह .NET कोर पोर्ट प्रयास से क्यों जुड़ा है?

हम "मजबूत पॉज़िक्स म्यूटेक्स" को कहाँ याद करते हैं?

NetBSD कर्नेल (और libc/libpthread) में, यह CoreCLR का एक भाग है। FreeBSD ने इसे पिछले दो वर्षों में विकसित किया है। यह नवीनतम स्थिर रिलीज़ में उपलब्ध हो सकता है .. लेकिन जाँच करने की आवश्यकता है।

मैं अपने .NET पोर्टिंग के पुनरारंभ होने से पहले इस सुविधा को जोड़ना चाहता हूं। (नेटवर्क रूटिंग के लिए एक छोटे से लापता एपीआई का भी पता चला था .. लेकिन मैं इसे अभी छोड़ देता हूं)।

क्या यह .NET कोर पाल का हिस्सा है?

मुझे अब याद नहीं है, कोड की जांच किए बिना - यह एपीआई है जिसका उपयोग .NET नामक मजबूत म्यूटेक्स (या शायद सेमाथोर) को लागू करने के लिए किया जाता है।

आप किस सीआई सिस्टम का जिक्र कर रहे हैं?

नेटबीएसडी।

यह .NET कोर पोर्ट प्रयास से क्यों जुड़ा है?

पिछली बार जब मैंने देखा तो यह वैकल्पिक सुविधा थी। मैंने कर्नेल-इंटरफेस और उपयोगिताओं (जैसे एलएलडीबी) पर फीचर-समता प्राप्त करने का निर्णय लिया। बस मेरी कार्यशैली, कार्यात्मक बिल्डिंगब्लॉक प्राप्त करने और बाद में एक घर बनाने के लिए। किसी बिंदु पर हमें इसकी आवश्यकता होगी, तो क्यों न इसे एक बार में विकसित किया जाए। समझने के लिए धन्यवाद :)

शायद आप केवल GH पर freebsd-dotnet समूह को टैग कर सकते हैं? वह वहां एक सदस्य है (या आप उसके खाते का नाम देख सकते हैं)। उनका ईमेल [email protected] है

[संपादित करें] @karelz . द्वारा सुनी गई ईमेल और पिछला उत्तर हटाएं

@RussellHaley बड़े समूह को टैग करने के लिए स्वतंत्र महसूस करें यदि आपको लगता है कि यह उचित है। मैं मैथ्यू के जीएच खाते को उसके नाम और ईमेल के माध्यम से नहीं ढूंढ सका, यही मेरा मतलब ऊपर था (बीटीडब्लू: मैंने उसे सीधे ईमेल पर पिंग किया)।

मैं समूह को टैग करने पर विचार करूंगा।

ये रहा मैथ्यू का एकाउंट। शायद एक गोपनीयता सेटिंग?

https://github.com/mprevot

चीयर्स,

रस

सोम, 18 सितंबर, 2017 को दोपहर 1:01 बजे, कारेल ज़िकमंड नोटिफिकेशन @github.com
लिखा था:

@RussellHaley https://github.com/russellhaley बेझिझक टैग करें
बड़ा समूह अगर आपको लगता है कि यह उचित है। मुझे Matheu's GH नहीं मिला
उसके नाम और न ही ईमेल के माध्यम से खाता, यही मेरा मतलब ऊपर था।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/dotnet/corefx/issues/1626#issuecomment-330338996 , या म्यूट करें
सूत्र
https://github.com/notifications/unsubscribe-auth/ACENF_N6mtOo3fptvku-LUMioNpZG7coks5sjswWgaJpZM4EPG-N
.

मैं यहां कहीं भी उल्लेखित नहीं देख सकता, लेकिन हम यहां फ्रीबीएसडी का कौन सा निम्नतम संस्करण लक्षित कर रहे हैं (मैं कम से कम 10 और बाद में मानता हूं, लेकिन शायद 9 भी)?
(मैं भी थोड़ा भ्रमित हूं कि मोनो @freebsd मेलिंग सूची पर क्या चर्चा होनी चाहिए, और यहां क्या?)

ठीक है, अगर फेडोरा कुछ भी हो जाए, तो एमएस केवल वर्तमान में समर्थित संस्करणों का समर्थन करेगा, अर्थात 10.3 (जल्द ही 10.4) और 11.1।

@radovanovic FreeBSD 9 अब समर्थित नहीं है, 10 अप्रैल 2018, 11 में 2021 में EoL होगा। मेरे अनुभव से 11 बनाम 10 (और यदि आप चाहें तो 9 भी) को संकलित करने में कोई समस्या नहीं होनी चाहिए। FreeBSD को पिछड़े संगतता को ध्यान में रखकर विकसित किया गया है।

@radovanovic मैं भी थोड़ा भ्रमित हूं कि मोनो @ फ्रीबीएसडी मेलिंग सूची पर क्या चर्चा होनी चाहिए, और यहां क्या है?

मुझे यहां पर तकनीकी चर्चा, काम के समन्वय और स्थिति की उम्मीद थी क्योंकि यह मोनो@फ्रीबीएसडी मेलिंग सूची की तुलना में व्यापक दर्शक हैं। ओटीओएच हम नहीं चाहते कि एक मुद्दे पर लाखों यादृच्छिक चर्चाएं हों, इसलिए हम कुछ विशिष्ट डिजाइन चर्चाओं को इस से अलग मुद्दों में ले सकते हैं यदि वे उचित संख्या में उत्तरों से ऊपर बढ़ते हैं।

मैं अंततः FreeBSD 11.0 (बाहरी लूप परीक्षणों के बिना) पर corefx परीक्षण चलाने में सक्षम था
कुल उत्तीर्ण: 144208
कुल विफल: 2622
कुल छोड़े गए 207

मैं निर्देशों के साथ https://github.com/dotnet/corefx/wiki/Building-.NET-Core--2.x-on-FreeBSD को अपडेट करूंगा। मैं विशिष्ट मुद्दों को दर्ज करूंगा और उन्हें ओएस-फ्रीबीएसडी और अप-फॉर-ग्रैब के साथ टैग करूंगा।
पूर्ण पैमाने पर लड़ाई शुरू हो सकती है। स्वयंसेवी आवश्यक।

और हाँ, मैंने प्रस्तावित चरण दो को छोड़ दिया। मैं उस पर भी वापस आऊंगा।

कुछ कार्य-प्रगति परिवर्तनों के साथ वर्तमान आँकड़े इस प्रकार दिखाई देते हैं:
कुल उत्तीर्ण: 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 टूटे कप सपोर्ट को ट्रैक करने के लिए खुला।

जबरदस्त प्रगति! फ्रीबीएसडी सपोर्ट इन-ट्री होने पर नेटबीएसडी जोड़ना आसान होना चाहिए।

@wfurt कृपया ई-मेल पता साझा करें, मैं कुछ पंक्तियां छोड़ दूंगा।

प्रारंभिक समर्थन को मास्टर शाखा में मिला दिया गया है। बिल्ड को विकी पेज पर बताए अनुसार काम करना चाहिए।
मैं dotnet/corefx#24386 पर धीरे-धीरे प्रगति कर रहा हूं लेकिन इससे अधिकांश उपयोगकर्ताओं को पीछे नहीं हटना चाहिए।

क्या हम पहले से ही FreeBSD पर .NET बूटस्ट्रैप कर सकते हैं?

मैंने थोड़ी देर के लिए कोशिश नहीं की है @krytarowski 2.0 रिलीज के लिए टूलिंग को अपडेट करने के लिए धक्का था और मैं उस प्रयास को स्थिर करने की प्रतीक्षा कर रहा था। मैं इसे एक और कोशिश दूंगा और मैं अपडेट पोस्ट करूंगा।

नमस्ते, इसलिए मैं clr प्रबंधित परीक्षणों के साथ नहीं चल रहा हूं। https://pastebin.com/B5KhtKX5

कोई भी इनपुट बहुत अच्छा होगा क्योंकि यह कुछ समय के लिए एक मुद्दा रहा है। मैंने हाल ही में विंडोज़ (मास्टर, गिट संशोधन 749194e) पर कोरएफएक्स बिल्डिंग पर बिल्ड विफलता में भी भाग लिया है। 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 त्रुटियों को छोड़ दिया:

विफल - जेआईटी/विधि/कास्ट/आईफेस/_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

यदि आपके पास एक पैच है जो टूटे हुए निर्माण को ठीक करता है, तो मैं इसे पुल-अनुरोध के रूप में भेजने की अनुशंसा करता हूं ताकि यह सभी के लिए तय हो जाए :)

धन्यवाद मैं करूंगा। मैं अभी भी परीक्षण चलाने के लिए काम कर रहा हूं और मुझे यकीन नहीं था कि कल रात बाद की त्रुटि क्या हो रही थी।

मुझे लगता है कि नेटकोर 2.1 (एक बार जारी होने के बाद) के लिए फ्रीबीएसडी 11 "पीकेजी इंस्टॉल" समर्थन नहीं होगा, है ना?

टीएलडीआर; बहुत काम किया गया है, लेकिन इसे घर चलाने के लिए किसी की जरूरत है। पोर्ट मेकफाइल लिखना आसान हिस्सा है।

@wfurt सीएलआर और एफएक्स को लिनक्स का उपयोग करके बनाने में सक्षम था लेकिन यह काफी हद तक

अलग से [email protected] मेलिंग सूची पर, @dragonsa ने लिनक्स एमुलेशन का उपयोग करते हुए मिंटोस से डॉट नेट कोर 1 और सभी टूलचेन (msbuild, nuget आदि) का एक बाइनरी संस्करण आयात किया है। मैं उनके पैच का उपयोग करने और कुछ टूल्स चलाने में सक्षम हूं लेकिन कुछ भी बनाने के लिए कभी नहीं मिला। मुझे यकीन नहीं है कि क्या ये पैच अभी तक प्रतिबद्ध हैं; मैं उनकी समीक्षा करने के बीच में था और मैंने नौकरी बदल दी। मेरी वर्तमान भूमिका में कोई डॉटनेट नहीं है और मैं अभी अन्य चीजों पर काम कर रहा हूं।

इस सब का क्या मतलब है? अगर कोई @dragonsa के पैच को सत्यापित कर सकता है तो वह उन्हें बंदरगाहों के पेड़ को धक्का दे सकता है, फिर मूल रूप से फ्रीबीएसडी पर कोर 2 बनाना तकनीकी रूप से संभव है। जैसा कि आप देख सकते हैं, हालांकि, बहुत से छोटे हिस्से हैं जिन्हें एक साथ लाने और व्यवस्थित करने की आवश्यकता है। मैंने उस पर गेंद गिरा दी है इसलिए किसी को इसे लेने की जरूरत है। मेरा सुझाव है कि आप [email protected] मेलिंग सूची पर https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/eresources-mail.html

@russellhadley राइटअप रसेल के लिए धन्यवाद।

नमस्ते,

यहां एक .NET देव के साथ इस पर चर्चा करते हुए, मैं एक फ्रीबीएसडी पोर्ट/पैकेज के विकास में सहायता करने के लिए तैयार हूं।

पूर्ण प्रकटीकरण: मैं .NET डेवलपर नहीं हूं, हालांकि मैं इसे ट्री में लाने के लिए किसी के भी साथ काम करने को तैयार हूं।

~ साइ

@cschuber मैं चीजों की वर्तमान स्थिति पर नजर रखने में बहुत व्यस्त हूं, लेकिन किसी ऐसे व्यक्ति के रूप में जिसने बहुत सारे फ्रीबीएसडी-पैच जमा किए और लगभग 3 साल पहले हैलो वर्ल्ड चलाने में कामयाब रहे, यह बहुत अच्छा होगा अगर हम अंत में देखें कि यह चीज ठीक से उतर रही है। आपको मेरा पूरा समर्थन है :)

@cschuber , वर्तमान सक्रिय मुद्दे https://github.com/dotnet/coreclr/issues/18067 हैं। मुख्य रूप से इन चार विशेषताओं को छोड़ दिया गया है https://github.com/dotnet/corefx/issues?q=is :open+ लेबल:os-freebsd+label :up-for-grabs+is:issue, जिनमें से फाइल सिस्टम वाचर लगता है सबसे मुश्किल/मज़ेदार एक https://github.com/dotnet/corefx/issues/2046।

@cschuber ऑफ़र के लिए धन्यवाद। हम लगभग उस बिंदु पर हैं जब यह संभव हो सकता है।
हम हाल ही में @mateusrodrigues के साथ .net को FreeBSD पर काम करने के लिए काम कर रहे हैं और वह PowerShell को काम करने की कोशिश कर रहा है। सूची @ kasper3 भेजी गई मुख्य रूप से अनुपलब्ध विशेषताएं हैं। मुझे लगता है कि हम अभी के लिए PNSP फेंक सकते हैं। मेरे संभावित सबसे अधिक दबाव वाले मुद्दे हैं dotnet/corefx#30698 और https://github.com/dotnet/coreclr/issues/18481। यह बहुत अच्छा होगा यदि समुदाय का कोई व्यक्ति उनमें खुदाई कर सके। मैंने हाल ही में परीक्षण नहीं किए, लेकिन मुझे डर है कि विफलताओं की संख्या बढ़ गई है।
हमें प्रत्येक नए असफल समूह के लिए अंक खोलना चाहिए।

मैं सोर्स-बिल्ड को ठीक करना भी शुरू करता हूं लेकिन अभी भी कुछ चुनौतियां हैं।
सी # कंपाइलर सी # में लिखा गया है। वर्तमान .net बिल्ड प्रबंधित असेंबली बनाने के लिए .net के पिछले संस्करण का उपयोग करता है। यह Nuget के पैकेज पर भी निर्भर करता है।
अभी, हमारे पास पर्याप्त बूटस्ट्रैप क्ली है जिससे हम FreeBSD पर coreclr, corefx और कुछ अन्य रेपो बना सकते हैं। मैंने 2.1 परिवर्तन और स्रोत-बिल्ड को प्रतिबिंबित करने के लिए अभी तक बिल्डिंग निर्देशों को अपडेट नहीं किया है।

+1 कहने के लिए बस एक नोट मुझे खुशी है कि इसमें अभी भी कुछ गति है। इतने सारे गतिशील भागों का अनुसरण करना कठिन है लेकिन ऐसा लगता है कि लोग प्रगति कर रहे हैं। मैंने कुछ समय पहले https://github.com/dotnet/coreclr/issues/6115 बनाया था, लेकिन जिस प्रोजेक्ट पर मैं काम कर रहा था, उसे रोक दिया गया। मैं वास्तव में आशा करता हूं कि यह pkg install dotnet && dotnet build एक दिन (लिनक्स कॉम्पैट के बिना) जितना आसान हो।

इसके लिए भी तत्पर हैं

हमें अब दैनिक निर्माण मिल रहे हैं। कोई यहां रनटाइम या एसडीके प्राप्त कर सकता है: 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

क्रॉस-टारगेट करना भी संभव है जैसे कि लिनक्स या विंडोज पर कोई dotnet publish -r freebsd-x64 और यह स्व-निहित फ्रीबीएसडी एप्लिकेशन बनाएगा।

यह अभी भी अधूरा और असमर्थित है लेकिन इसे किसी के लिए भी योगदान करना आसान बनाना चाहिए।
यह बहुत अच्छा होगा यदि लोग इसे आजमा सकते हैं, मुद्दों की रिपोर्ट कर सकते हैं।
साथ ही फीचर गैप को बंद करने और बग्स को ठीक करने के लिए अंतिम पुश के लिए यह अच्छा समय होगा।

cc: @mateusrodrigues

अच्छा काम, @wfurt और @bartonjs।

जब मैंने लगभग 2-3 साल पहले अपना पहला फ्रीबीएसडी कमिट करने का प्रस्ताव दिया, तो मुझे वास्तव में विश्वास नहीं था

यह निश्चित रूप से एक बड़ा मील का पत्थर है और उम्मीद है कि नए योगदानकर्ताओं के लिए बंदरगाह को खत्म करने में मदद मिलेगी।

उन सभी का बहुत-बहुत धन्यवाद जिन्होंने हमें यहां तक ​​पहुंचाने में मदद की

जबरदस्त प्रगति! मैं अभी भी टूलचेन के साथ लड़ रहा हूं (एलएलडीबी और एलएलडी के अलावा अधिकांश एलएलवीएम परियोजनाएं समाप्त हो चुकी हैं) और नेटबीएसडी के लिए हार्डवेयर सहायता प्राप्त वर्चुअलाइजेशन (लिनक्स/बीएसडी अब वीटीएक्स घातक अपवाद तक बूट करना शुरू कर देता है, फ्रीडॉस जैसे सरल ओएस पहले से ही काम करते हैं) .. इसलिए मैं फिर से शुरू करूंगा मेरी नेटबीएसडी पोर्टिंग, उम्मीद है कि जल्द से जल्द। बेहतर फ्रीबीएसडी सपोर्ट एक आसान रिज्यूमे में मदद करेगा।

बहुत बढ़िया :)

हम नशे का जश्न मनाते हैं तो बम क्यों बरसते हैं ??

@krytarowski क्या आप 'फ्रीबीएसडी सपोर्ट' बेहतर तरीके से विकसित कर सकते हैं?

यह बहुत अच्छा होगा अगर कुछ फ्रीबीएसडी गुरु https://github.com/dotnet/coreclr/issues/22124 पर देख सकते हैं, मैं उम्मीद करता हूं कि बाइनरी 11 के लिए 12 पर चलने के लिए निर्माण करेगी लेकिन ऐसा नहीं लगता है ;(
सरल ऐप के साथ पुन: पेश करना आसान है और 12.0 रिलीज ऐसा लगता है कि कुछ डॉटनेट पर निर्भर करता है।

नमस्ते, मैं कोई गुरु नहीं हूं, लेकिन हम Lua53 पोर्ट में 12-रिलीज में एक थ्रेडिंग रिग्रेशन में भागे।
मूल बग के लिए यहां देखें: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235158
और यहां बेस सिस्टम बग की पहचान की गई थी: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235211 (ध्यान दें कि बेस सिस्टम बग उस कोड की पहचान करता है जिसका उपयोग तुलना के लिए समस्या को पुन: उत्पन्न करने के लिए किया जा सकता है)।

लुआ के लिए फिक्स -पथ्रेड के खिलाफ लिंक करना है, भले ही लुआ से -प्थ्रेड के लिए शून्य आवश्यकता है।

धन्यवाद @RussellHaley। यह आशाजनक नेतृत्व की तरह दिखता है।

मुझे खुशी है कि मुझसे मदद हो सकी। मुझे साथ खेलना अच्छा लगेगा लेकिन लुआ बंदरगाह को बनाए रखने के लिए मेरे पास मुश्किल से कुछ घंटे हैं। अच्छा काम करते रहो!

कोरक्लर में फ्रीबीएसडी थ्रेडिंग कार्यान्वयन को ठीक करने वाले के रूप में , मुझे लगता है कि

उस ने कहा, अंतर्निहित लेकिन टुकड़े और टुकड़े हो सकते हैं जिन्हें मुझे कभी छूना नहीं पड़ा जो "नियमित" धागे का उपयोग करता है ...

हो सकता है कि कोई और जो सामान्य कार्यान्वयन के बारे में अधिक जानता हो, वह इसमें शामिल हो सकता है? @जानवर्ली ?

यह मेरे लिए इस मुद्दे को ठीक करता है:

[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 फिर से निष्पादित कर सकता हूं।

ठीक है, मैं देख सकता हूं कि डॉटनेट निष्पादन योग्य लिनक्स के अलावा अन्य प्रणालियों के लिए pthreads से जुड़ा नहीं है।
https://github.com/dotnet/core-setup/blob/2ef0b64810530961f492c33d37fc7509128e0a9b/src/corehost/cli/exe.cmake#L59 -L61

क्या इसका मतलब यह है कि इसे ठीक करने का उत्तर उतना आसान है जितना लगता है? यानी इतना आसान? https://github.com/josteink/core-setup/commit/25657ba2e181cce401acd7f4bf9d27a08a668470

अगर ऐसा है, तो मुझे इसे पीआर बनाने में खुशी होगी।

हां मुझे ऐसा लगता है। मैं पुष्टि करने के लिए @joperator की प्रतीक्षा कर रहा था।
सुनिश्चित नहीं है कि हमें "डीएल" की भी आवश्यकता है, लेकिन जब आप पीआर जमा करते हैं तो इसे हल किया जा सकता है @josteink

सही। मेरा बुरा। तो इस तरह और अधिक: https://github.com/josteink/core-setup/commit/a08f38e25a98c25f59c8ed8c8567a0cb08b1c1c6

मैंने इसके लिए एक पीआर बनाया है। मुझे बताएं कि क्या इसमें किसी संशोधन की आवश्यकता है: https://github.com/dotnet/core-setup/pull/5072

सही। मेरा बुरा। तो इस तरह और अधिक: josteink/ core-setup@a08f38e

मैंने इसके लिए एक पीआर बनाया है। मुझे बताएं कि क्या इसमें किसी संशोधन की आवश्यकता है: dotnet/core-setup#5072

सिर्फ एक FYI करें, ऐसा लगता है कि यह पहले से ही आधार प्रणाली में पैच किया गया है: https://reviews.freebsd.org/D18988

ऐसा लगता है कि dotnet/coreclr#22124 में मुख्य समस्या
फ्रीबीएसडी 12.0 पर एक स्व-निहित ऐप प्रकाशित करने का प्रयास करते समय मुझे केवल एक समस्या है।

freebsd-x64 आधिकारिक NuGet पैकेज .NET Core 3.0 पूर्वावलोकन 2 के बाद से हटा दिए गए हैं और तब से हम FreeBSD के लिए ऐप्स प्रकाशित करने में असमर्थ थे। क्या उन्हें 3.0 में पुन: सक्षम करने की कोई योजना है?

अफसोस की बात है कि हमें फ्रीबीएसडी लाने को प्राथमिकता देना पड़ा (विभिन्न कारणों और एंड-टू-एंड एज़ूर समर्थन में कठिनाइयों के कारण) और यह .NET कोर 3.0 में प्राथमिकता नहीं होगी।
हम इसे उस राज्य में अर्ध-कार्यशील रखना पसंद करेंगे जहां यह अभी है, लेकिन हमारे पास अभी निवेश करने के लिए ज्यादा समय नहीं है :(।

@karelz आपके उत्तर के लिए धन्यवाद और मैं .NET Core 3.0 के प्राथमिकता वाले कार्य को समझता हूं। मैं तब अपने ऐप्स को फ्रीबीएसडी लिनक्स एमुलेशन के साथ लाने पर ध्यान दूंगा। :)

@ hjc4869 या आप मोनो आज़मा सकते हैं। आईआईआरसी, यह .NET मानक 3.0 का समर्थन करेगा

मैं इसे एक और कोशिश देने की योजना बना रहा हूं लेकिन जैसा कि @karelz ने उल्लेख किया है कि यह 3.0 के लिए प्राथमिकता नहीं है

@newsash मोनो मेरे लिए एक स्वीकार्य विकल्प है। हालांकि मुझे मौजूदा .NET कोर csproj फाइलों में जोड़े गए मोनो लक्ष्यों के साथ अपना प्रोजेक्ट बनाना मुश्किल लगा।

एक लिनक्स मशीन पर मैंने net472 को टारगेटफ्रेमवर्क में जोड़ने और फ्रेमवर्कपाथऑवरराइड वैरिएबल को सेट करने की कोशिश की, लेकिन यह अच्छी तरह से काम नहीं किया। अगर मैं एक एपीआई का उपभोग करता हूं जो मोनो और .NET कोर दोनों में लागू किया गया है, लेकिन .NET फ्रेमवर्क नहीं है, तो यह मोनो के साथ निर्माण करने में विफल रहेगा। इसके अलावा, हालांकि मोनो .NET मानक 2.1 का समर्थन करता है, फिर भी मैं net472 csproj में .NET मानक 2.1 dll का संदर्भ नहीं जोड़ सका।

क्या मुझे एक अलग csproj जोड़ना चाहिए और डॉटनेट टूल्स का उपयोग करने के बजाय मोनो एमएसबिल्ड का उपयोग करना चाहिए, या क्या आपके पास समस्या पर कोई सुझाव है?

बस एक त्वरित टिप्पणी।

हाल की घोषणा [1] के अनुसार मोनो को .NET 5 द्वारा निगल लिया जाना है, फ्रीबीएसडी के लिए उचित समर्थन प्रदान करना अत्यावश्यक हो गया है।

मोनो वास्तव में अच्छा क्रॉस-प्लेटफ़ॉर्म समर्थन साबित हुआ है और इसे फ्रीबीएसडी बंदरगाहों से बिना किसी समस्या के बनाया जा सकता है। कई दुकानें फ्रीबीएसडी पर अपना नेट लोड चलाती हैं क्योंकि इस ओएस में कई अनूठी विशेषताएं हैं। अब तक, मोनो इस अंतर को पाटता रहा है, लेकिन .NET 5 के साथ ऐसा लगता है कि निकट भविष्य में, मोनो को NET 5 में मिला दिया जाएगा और FreeBSD समुदाय .NET पारिस्थितिकी तंत्र से पूरी तरह से अलग हो जाएगा।

ऐसा होने से पहले डॉटनेट के पास परिपक्व फ्रीबीएसडी समर्थन होना चाहिए।

मुझे लगता है कि माइक्रोसॉफ्ट को इस समय आधिकारिक तौर पर फ्रीबीएसडी का समर्थन करना चाहिए और यह सुनिश्चित करना चाहिए कि इस प्लेटफॉर्म पर सभी डॉटनेट टूलिंग का निर्माण हो।

@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 , इन दिनों फ्रीबीएसडी सीआई लेग (उबंटू से क्रॉस- https://github.com/dotnet/dotnet-buildtools-prereqs-docker/ से एक डॉकर छवि का उपयोग करता है, जिसमें सभी प्रीरेक स्थापित हैं। हम स्थानीय या दूरस्थ मशीन रनटाइम पैकेज (मूल रूप से एक tar.gz) प्रकाशित करने के लिए उसी डॉकटर कंटेनर का उपयोग कर सकते हैं। उदाहरण के लिए, हम अपनी कांटा शाखा में से एक में गिटहब एक्शन सेट कर सकते हैं, जैसे कुछ: https://github.com/am11/runtime/blob/feature/freebsd/ci/.github/workflows/main.yml , जो कलाकृतियों को अपलोड करता है टैग पुश पर गिटहब रिलीज के लिए https://github.com/am11/runtime/releases/tag/6.0.0-dev.freebsd.1। इस मामले में dotnet-runtime-6.0.0-dev-freebsd-x64.tar.gz संग्रह में एक प्रकाशित डॉटनेट एप्लिकेशन को चलाने के लिए पर्याप्त बिट्स हैं (एक अलग लिनक्स/मैक सिस्टम से, जिसमें डॉटनेट एसडीके है)। मैंने एक नया 12.2 वीएम (आवारा) बनाकर इसका परीक्षण किया, मैक से वीएम में एक प्रकाशित ऐप निकाला और कॉपी किया, इसने काम किया:

#!/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 पर देखना चाहेंगे
मैंने हाल ही में कोशिश नहीं की है क्योंकि मैं डॉटनेट 5 फाइनल की प्रतीक्षा करता हूं, लेकिन कुछ महीने पहले, फ्रीबीएसडी रनटाइम केवल लिनक्स पर क्रॉस कंपाइल के रूप में बनाया जा सकता था। एएसपीनेट और एसडीके को भी लिनक्स क्रॉस कंपाइल की आवश्यकता होती है, लेकिन केवल तभी बनाया जाता है जब सितारे संरेखित हों (आर्केड अपडेट या कुछ अन्य स्वचालित बॉट ने निर्भरता को नहीं तोड़ा)

संपादित करें: और @ am11 ने एक बेहतर लेखन पोस्ट किया, जब मैं देर रात की
संपादित 2: विराम चिह्न भूल गया और ऐसा लगता है कि अंतिम 2 दिन पहले बाहर रखा गया था। लगता है मुझे उस पर काम करना चाहिए या कुछ और

उपरोक्त सभी के अलावा, मैंने https://github.com/dotnet/runtimelab/ में FreeBSD प्रोजेक्ट बनाया और मैं धीरे-धीरे पैकेज बनाने और प्रकाशित करने की दिशा में आगे बढ़ रहा हूं। लक्ष्य फ्रीबीएसडी पर चलने के लिए ऐप के निर्माण और प्रकाशन के लिए पर्याप्त है और स्रोत-निर्माण के लिए बीज है।

मैंने सोचा कि मैं एक त्वरित अद्यतन लिखूंगा। मैंने आखिरकार सभी ग्रहों को फ्रीबीएसडी पर 5.0.0 आरटीएम बनाने के लिए गठबंधन किया। मैंने पूर्वावलोकन 3 के बाद से नहीं रखा था और एक सफल 5.0 प्राप्त करने के लिए संगत बिल्ड का सही संयोजन खोजने में कुछ समय (और _many_ बिल्ड प्रयास) लगा।
मैं आश्चर्यजनक रूप से कुछ हैक्स के साथ पावरशेल 7.1.0 बनाने में सक्षम हूं, यह काम करता है हालांकि मैंने इसे पूरी तरह से परीक्षण नहीं किया है लेकिन यह एसडीके के एक अच्छे परीक्षण की तरह लगता है।
मैंने अभी-अभी 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>

इस काम को मैन्युअल रूप से करने के साथ एकमात्र समस्या (यानी सीआई सिस्टम के बाहर) एक विशेष बिल्ड को उपयोग करने के लिए अगले निर्माण के लिए उपलब्ध होने वाले परिवर्तनों को तोड़ने के कारण होने वाली परेशानी है। यह अक्सर नहीं होता है लेकिन सही प्रतिबद्धता खोजने के लिए इसे बहुत सारे परीक्षण और त्रुटि की आवश्यकता होती है। सीआई सिस्टम में लिनक्स क्रॉस-बिल्ड होने से इसे ठीक करना चाहिए लेकिन मैंने अभी तक उस पर ध्यान नहीं दिया है। फिर भी यह जानना अच्छा है कि मैं एक पूर्ण एसडीके बना सकता हूं और फिर उस एसडीके का उपयोग कुछ और बनाने के लिए कर सकता हूं।

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। मैं निर्माण के लिए बेहतर उत्तर खोजने की कोशिश कर रहा हूं लेकिन मैं पिछले कुछ महीनों में समय का कोई अच्छा हिस्सा नहीं लगा पाया ;(
क्या टर्मिनो के कारण पावरशेल ने आपको कोई दुःख दिया या आपने टर्मिनल परिभाषा को कहीं और से कॉपी किया?

मैंने अपने मैक से टर्मिनल परिभाषा को पकड़ लिया जहां से मैं ssh'd था।

@jasonpugsley तुम मुझसे बहुत आगे हो। कोर और एसडीके लिनक्स क्रॉस फ्रीबीएसडी से निर्मित होते हैं। किए गए सीमित परीक्षण से ठीक चलाएं। न तो रनटाइम और न ही एसडीके क्रॉसबिल्ट स्वयं फ्रीबीएसडी पर निर्माण करने में सक्षम हैं (लिनक्स और फ्रीबीएसडी एलएलवीएम 9 और क्लैंग 9 का उपयोग कर रहे हैं)।
ld: error: /root/runtime/artifacts/obj/coreclr/FreeBSD.x64.Release/src/dlls/dbgshim/dbgshim.exports:1: unknown directive: V1.0
अगर मेरे पास इस सप्ताह के अंत में अधिक समय है तो मैं इसे थोड़ा और अधिक परेशान करता हूं और यह भी देखता हूं कि क्या मैं कम से कम फ्रीबीएसडी के लिए लिनक्स पर एस्पनेटकोर बना सकता हूं

@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 में बायनेरिज़ निष्पादित करने में विफल रहा है?
यदि आप Ubuntu 18 या 20 पर SDK 5x को क्रॉसकंपाइल करने का प्रयास कर रहे हैं, तो आप इस पैच को https://github.com/dotnet/sdk/commit/80e42f16422352f725d78be72071781d8365a238 (यह मास्टर ब्रांच पर है) लागू करना चाह सकते हैं।

आधी नींद में मुझे वास्तव में पोस्ट करना बंद करने की आवश्यकता है।
रनटाइम और एसडीके का निर्माण लिनक्स पर पूरा होता है।
वे बायनेरिज़ फ्रीबीएसडी पर चलते हैं (डॉटनेट --इन्फो, नया कंसोल, और रन)
वे बायनेरिज़ फ्रीबीएसडी पर स्रोत से रनटाइम या एसडीके बनाने में असमर्थ हैं

आह अच्छा। मैंने फ्रीबीएसडी पर होस्टओएस के रूप में रनटाइम को फिर से बनाने के लिए स्टेज 0 बायनेरिज़ को डॉगफ़ोडिंग करने की कोशिश नहीं की है।

एलडी: त्रुटि: /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)

क्या इस पैच से कोई फर्क पड़ता है

मैं उम्मीद करता हूं कि फ्रीबीएसडी लिनक्स का पालन करेगा जहां तक ​​​​प्रतीक संस्करण स्क्रिप्ट जाते हैं, डार्विन नहीं। IMO यह अधिक संभावना है कि मुद्दा यह है कि कुछ GNU-awk है जो generateversionscript.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)

यदि प्रयोग करना आसान है, तो क्या आप गॉक पैकेज को स्थापित करने का प्रयास कर सकते हैं और सीएमके फाइलों में इनवोकेशन को गॉक में बदल सकते हैं?

पैच वापस कर दिया। स्थापित गॉक पीकेजी।
यह पता लगाने के लिए बहुत आलसी है कि कैसे 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

देर से संपादित करें: ऐसा लगता है कि लिनक्स पर बायनेरिज़ सही तरीके से नहीं बने हैं:

# ./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 सही है, अन्यथा एप्लिकेशन (जैसे 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 प्रिंट करता है।

एलडी मुद्दे को ट्रैक करने के लिए #45663 खोला गया। मैं भी प्रजनन करने में सक्षम था।

@Thefrank एलडी त्रुटि के संबंध में, इसे आजमाएं:

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)

यह else क्लॉज को यहां eng/native/functions.cmake सक्रिय करेगा:

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

काफी ईमानदार होने के लिए, मैं कोई लिंकर विशेषज्ञ नहीं हूं, इसलिए जब यह काम करता है, तो मैंने यह देखने के लिए गहराई से नहीं देखा कि वास्तव में फ्रीबीएसडी पर क्लैंग के लिए क्या आवश्यक/विहित था।

आह, लिंकर उपयोगकर्ता-एजेंट मुद्दा फिर से हमला करता है। एलएलडी के संस्करण स्ट्रिंग में कॉन्फ़िगर परीक्षणों के जीएनयू एलडी पथ को नीचे जाने के प्रयास में (compatible with GNU linkers) है लेकिन स्पष्ट रूप से इस मामले के लिए पर्याप्त चालाक नहीं है :)

LLD पर मिलान यहाँ अच्छा लगता है, भले ही LD_GNU ध्वज का नाम अब कुछ गलत हो।

हां इसे और काम करने की जरूरत है। ध्वज का नाम अब भ्रमित करने वाला है। कृपया कोई भी इसे इस रूप में करने का प्रयास न करें।

प्रेषक: एड मास्ट नोटिफिकेशन @github.com
भेजा गया: सोमवार, 7 दिसंबर, 2020 10:26:48 पूर्वाह्न
प्रति: डॉटनेट /रनटाइम रनटाइम
सीसी: जेसन पगस्ले [email protected] ; उल्लेख करें @noreply.github.com
विषय: पुन: [डॉटनेट/रनटाइम] फ्रीबीएसडी के लिए समर्थन (#14537)

आह, लिंकर उपयोगकर्ता-एजेंट मुद्दा फिर से हमला करता है। एलएलडी के संस्करण स्ट्रिंग में कॉन्फ़िगरेशन परीक्षणों के जीएनयू एलडी पथ को नीचे जाने के प्रयास में (जीएनयू लिंकर्स के साथ संगत) शामिल है लेकिन इस मामले के लिए स्पष्ट रूप से पर्याप्त चालाक नहीं है :)

LLD पर मिलान यहाँ अच्छा लगता है, भले ही LD_GNU फ़्लैग का नाम अब कुछ गलत हो।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे 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]

सबसेट "मोनो" और सबसेट "लिबास" बिना किसी त्रुटि के पूरा होता है

@Thefrank यह इस अंतर का दूसरा भाग है जिसे आपको उस समस्या को ठीक करने की आवश्यकता है:

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>

इसे LINUX लाइन में OR के रूप में बेहतर तरीके से जोड़ा जा सकता है।

@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):
मुझे पता था कि मैं कुछ दिन पहले कुछ करना भूल गया था! यह दिलचस्प होना चाहिए

संपादित करें: क्रॉसजेन के बिना (उर्फ सिर्फ दूसरी छमाही)

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

2hr प्रतीक्षा के बाद परीक्षण को मार दिया अन्य परीक्षण अभी भी विफल थे

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