Runtime: دعم FreeBSD

يبدو أن هناك اتفاقًا فيما يتعلق بـ https://github.com/dotnet/corefx/issues/1576 .

عندما يكون لدينا أيضًا قرار بشأن https://github.com/dotnet/corefx/issues/1625 ، يجب أن نتمكن من بدء شحن بعض الأكواد.

تم التوصل إلى اتفاق على dotnet / وقت التشغيل # 14536 بواسطة portteam ، ما لم تختر MSFT خلاف ذلك فسيكون FreeBSD . من المحتمل أن تكون المشكلة dotnet / corefx # 1999 هي المشكلة التي تقدم التعريف في واجهة برمجة التطبيقات العامة.

تم التوصل إلى اتفاق على dotnet / وقت التشغيل # 14536 بواسطة portteam ، ما لم تختر MSFT خلاف ذلك سيكون FreeBSD

إذا قرأت ذلك بشكل صحيح ، فهذا يعني أنه عند دمج https://github.com/dotnet/corefx/pull/1999 ، يمكننا اعتبار اعتماد MSFT هذا لواجهة برمجة التطبيقات العامة الجديدة ، وبالتالي يمكننا المضي قدمًا بشأن المشكلات المتبقية مع طلبات السحب المنتظمة دون الحاجة إلى موافقة MSFT.

إذا كان الأمر كذلك ، فهذا يبدو جيدًا بالنسبة لي.

الخطوات التالية حسب https://github.com/dotnet/corefx/pull/1999#issuecomment -111279577 هي:

1. يواصل "فريق FreeBSD port" عملهم للحصول على نسخة FreeBSD من CoreFX المنتجة (تتبعها dotnet / corefx # 1626).
2. يقوم فريق المنفذ بإحضار ما يكفي من مكدس CoreFX و CoreCLR على FreeBSD بحيث يمكننا بدء تشغيل اختبارات وحدة CoreFX على FreeBSD.
3. تصل الاختبارات إلى حد أدنى من الجودة. لا أعرف بالضبط كيف يبدو هذا حتى الآن ، لكنني أتوقع أنه يعني شيئًا مثل اجتياز غالبية الاختبارات. من الناحية المثالية ، لن يكون لدينا مجموعة من الاختبارات المحددة معطلة لـ FreeBSD فقط (مقارنةً بـ Linux و OSX ، لا نريد أن نضع FreeBSD على مستوى أعلى من منصات * NIX الأخرى الموجودة لدينا).
4. من خلال العمل مع فريق FreeBSD port ، حصل فريق CoreFX على اختبارات CoreFX المضافة إلى نظام CI الخاص بنا الذي يعمل على FreeBSD.
5. ناقش دمج PR على أساس المشكلة dotnet / runtime # 14536 ، والتي تضيف الخاصية.

هذا يبدو وكأنه خطة معقولة تماما بالنسبة لي.

حسنًا ، لنبدأ العمل على تشغيل corefx.

يبدو أن العقبة الأولى في بناء corefx على FreeBSD أحادية. يصر البرنامج النصي للبناء على أن الإصدار 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.

يبدو أن العقبة الأولى في بناء corefx على FreeBSD أحادية

FWIW ، أنا شخصياً لا أعتقد أن هذه هي العقبة الأولى. هناك نوعان من المشاكل المتعلقة بالبناء:

1. تجميعات البناء التي تعمل بشكل صحيح على FreeBSD
2. بناء تلك التجمعات على FreeBSD

(1) أمر بالغ الأهمية ، وأنا أؤمن بما يجب أن تكون عليه هذه القضية. (2) من الجيد جدًا امتلاكه ، لكن عدم وجوده لا يمنع إنشاء نظام رائع لتشغيل التعليمات البرمجية المدارة على FreeBSD.

أنت بالطبع حر في تحديد الأولويات كما تراه مناسبًا ، لكن توصيتي ستكون التركيز على (1) بدلاً من (2).

لاحظ أنه لا يزال لدينا مشكلات في إنشاء corefx على Linux وإنشائه على OSX ، بحيث يقوم نظام CI الخاص بنا ببناء التجميعات لتلك الأنظمة الأساسية على Windows ؛ ثم ينقل التجميعات الناتجة إلى النظام الأساسي المستهدف لتنفيذ الاختبارات.

هدا يبدو عادلا. لقد افترضت للتو أنه سيكون من الأسهل الحصول على دعم عام لمنصة FreeBSD مخبوزًا في corefx إذا تمكنا بالفعل من بنائه بأنفسنا على FreeBSD.

سأفعل البناء الذي بدأه Windows في الوقت الحالي وسأحاول تكوين تكوين بناء معًا.

تضمين التغريدة يجب الآن بناء corefx على Mono 4.0.1.44.

تضمين التغريدة هذا يترك لي بعض الأمل في أن نتمكن من تشغيله على FreeBSD أيضًا :)

نقاط جيدة. ومع ذلك ، إذا كنا نريد حقًا أن تكون corefx جزءًا من بيئة FreeBSD ، فنحن نحتاجها حقًا لتكون قادرة على التجميع من المصدر لإدخالها في نظام المنافذ.

لقد سمعت أن Mono 4.0.1.44 يعمل على إصلاح الكثير من هذه المشكلات ولكن لم يتح لي الوقت للعب بها حتى الآن. أعلم أن فريق المنافذ يقوم بتحديث المنفذ Makefile وكذلك نتحدث مع تصحيح جديد.

في 12 حزيران (يونيو) 2015 ، الساعة 20:21 ، كتب ستيفن توب [email protected] :

يبدو أن العقبة الأولى في بناء corefx على FreeBSD أحادية

FWIW ، أنا شخصياً لا أعتقد أن هذه هي العقبة الأولى. هناك نوعان من المشاكل المتعلقة بالبناء:

تجميعات البناء التي تعمل بشكل صحيح على FreeBSD
بناء تلك التجمعات على FreeBSD
(1) أمر بالغ الأهمية ، وأنا أؤمن بما يجب أن تكون عليه هذه القضية. (2) من الجيد جدًا امتلاكه ، لكن عدم وجوده لا يمنع إنشاء نظام رائع لتشغيل التعليمات البرمجية المدارة على FreeBSD.

أنت بالطبع حر في تحديد الأولويات كما تراه مناسبًا ، لكن توصيتي ستكون التركيز على (1) بدلاً من (2).

لاحظ أنه بالكاد لدينا corefx build-on-Linux و build-on-OSX ، مثل أن نظام CI الخاص بنا يبني التجميعات لتلك الأنظمة الأساسية على Windows ؛ ثم ينقل التجميعات الناتجة إلى النظام الأساسي المستهدف لتنفيذ الاختبارات.

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub.

نعم ، أنا لا أعارض بأي حال من الأحوال ... من المهم أن تكون قادرًا على بناء_ corefx على Linux و OSX و FreeBSD. أنا أقترح ببساطة أنه من منظور الأولوية ، من الأهمية بمكان أن تكون قادرًا بالفعل على تشغيل _run_ corefx على Linux و OSX و FreeBSD. : wink: إذا كان بالإمكان العمل على كليهما بالتوازي ، فكلما كان ذلك أفضل.

ghuntley ،
سيكون رائعًا: رائعًا: إذا كانت لدينا قائمة مرجعية لمهمة تخفيض السعر تحدد ما تبقى:

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

يجعل على النحو التالي:

• [ ] مهمة 1
• [] المهمة 2
• [] المهمة 3

من المحتمل أن يشجع هذا الآخرين على تحقيق تلك المآثر وسيهبط دعم FreeBSD في وقت أقرب مما كان متوقعًا! :نظارة شمسيه:

على حد علمي ، فإن أجزاء العمل التالية في CoreFX مطلوبة لدعم FreeBSD:

• [x] تقديم منصة FreeBSD لأدوات البناء والبرامج النصية. (تم بواسطة josteink وأنا ، تم دمج العلاقات العامة dotnet / corefx # 2021 ، تم دمج dotnet / corefx # 2030)

13 التجميعات لا تقوم بالتجميع من تلقاء نفسها وتحتاج إلى تغييرات محددة من FreeBSD. في الغالب ، قطع التشغيل المتداخل الموجودة بالفعل لنظام التشغيل Linux / OS X (الترتيب حسب التواجد في إخراج البناء):

• [x] System.Private.URI (تم ، تم دمج شبكة العلاقات العامة / corefx # 2032)
• [x] System.Console (تم ، تم دمج شبكة العلاقات العامة / corefx # 2031)
• [x] System.Diagnostics.Debug (تم ، تم دمج شبكة العلاقات العامة / corefx # 2039)
• [x] System.Diagnostics.Process (مناقشة dotnet / corefx # 2070 ، PR dotnet / corefx # 3257)
• [x] System.IO.Compression.ZipFile (تم ، تم دمج شبكة العلاقات العامة / 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 (تم ، تم دمج شبكة العلاقات العامة / 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 (تم ، تم دمج شبكة العلاقات العامة / corefx # 2040)
• [x] System.Security.SecureString (تم ، تم دمج شبكة العلاقات العامة / corefx # 2039)
• [x] System.Runtime.Environment (تم حظره بواسطة dotnet / corefx # 1999)
• [x] System.Runtime.InteropServices.RuntimInformation (تم ، تم دمج شبكة العلاقات العامة / corefx # 2068)

سأحاول تحديث تلك القائمة بناءً على العلاقات العامة المفتوحة والمدمجة.

لمعلوماتك: تم دمج dotnet / corefx # 2039 للعلاقات العامة

فقط أحاول أن تكون في الطليعة هنا ... كيف نخطط لتنفيذ System.IO.FileSystem.Watcher ؟

لا تحتوي Iirc FreeBSD على inotify مثل Linux و Windows (وهذا أيضًا سبب عدم وجود Dropbox آخر مرة راجعت فيها). هل سيكون هذا مصدرًا محتملاً للمشاكل القادمة في طريقنا؟ أو هل لدى أي شخص فكرة عن كيفية التغلب على هذا؟

أقترح أن نوقف ذلك في الوقت الحالي ونرمي PlatformNotSupportedException كما اقترح ستيفن توب في الموضوع الآخر (https://github.com/dotnet/corefx/pull/2021#issuecomment-111602342). ثم لدينا على الأقل مجموعة كاملة من التجميعات ويمكننا متابعة العمل على هذه المشكلة بالذات دون حظر المزيد من الخطوات.

هل تمانع في فتح قضية منفصلة لذلك؟

دعنا ننقل مناقشات System.IO.FileSystem.Watcher إلى dotnet / corefx # 2046

الرجال هل هناك أي مانع من هذا القبيل لـ System.Diagnostics.Process ؟

أضاف @ jasonwilliams200OK FreeBSD إلى S.RT.I.RI في وقت مبكر من هذا الصباح والذي تم دمجه ولكن اختبارات FreeBSD في حدود CheckPlatformTests يجب أن يتم دعمها حتى يتم تحديث dotnet/buildtools .

• [] تحديث أدوات البناء لدعم FreeBSD - https://github.com/dotnet/buildtools/pull/180
• [] أعد تطبيق اختبارات [Fact,PlatformSpecific(PlatformID.FreeBSD)] على CheckPlatformTests - راجع https://github.com/dotnet/corefx/pull/2068#discussion_r32570244 و https://github.com/dotnet/corefx/pull/2068#discussion_r32570244
• [] أضف public static OSPlatform FreeBSD إلى https://github.com/dotnet/corefx/pull/2068

@ jasonwilliams200OK كانت هناك بعض المناقشات الليلة الماضية حول System.Diagnostics.Process في gitter والتي تمت صياغتها في https://github.com/dotnet/corefx/issues/2070

ghuntley ، شكرًا. أنا في الواقع قرأت تلك الرسائل. System.Diagnostics.Process هو أمر صعب. واجه فريق AFAIK و io.js تحديات مماثلة مع إدارة عملية FreeBSD. من المحتمل أن يكون فريق Mono قد نجح في ذلك ، لذلك دعونا نأمل إذا

System.IO.FileSystem.DriveInfo

كما تمت مناقشته في gitter ، بالنسبة لهذا الشخص حاولت النظر في الاستخدام الأساسي لـ getmntinfo :

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

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

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

أدى تشغيل هذه العينة إلى هذا الناتج:

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

لذلك يبدو أنه يفعل ما نحتاجه. السؤال هو ، هل يجب أن نقوم بأي نوع من التصفية على النتائج؟

بالنظر إلى "الهدف" الخاص بالعنصر DriveInfo ، الذي يأتي من عالم Windows الخاص بـ .NET ، غالبًا ما كان يتم تعداد المواقع المتاحة لتخزين أو استرداد الملفات ( C: ، D: ، وما إلى ذلك). ولكن عند استخدام أنظمة الملفات الهرمية لـ Unix ، فإن إرجاع / سيكون كافياً لتغطية تلك الاحتياجات.

إذن ماذا يجب أن نعود؟ ماذا سيكون مفيد؟ هل يجب اعتبارها مفيدة أم لا؟

يقوم إصدار Linux بتفريغ كل شيء ، باستثناء الأشياء التي سيتم تجاهلها:

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

حاولت وضع الفلتر التالي ، لكنه لم يغير شيئًا من حيث المخرجات:

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

أي آراء؟

@ josteink ، حفريات عظيمة! استنادًا إلى https://github.com/dotnet/corefx/issues/815#issuecomment -113825960 و https://github.com/dotnet/corefx/issues/1729 ، أعتقد أنه يجب علينا التعاون مع sokket للتوصل إلى حل مع أعمال عبر مختلف الوحدات.

لدي إصدار يعمل على OSX يستخدم getmntinfo و statfs للحصول على معلومات حول كل نقطة تحميل ، والتي تبدو أكثر الخرائط منطقية من مفهوم Windows Drive. سوف أتحقق مرة أخرى من أن تعريفات الوظيفة والبنية في OSX تتطابق مع تعريفات FreeBSD ، وإذا كان الأمر كذلك ، فسيعمل التزامي بـ OSX مع BSD أيضًا.

سأكون على يقين من إضافتك إلى العلاقات العامة الخاصة بي josteink

يبدو جيدا. شكرًا على التنبيه وشكرًا لمنح FreeBSD بعض الحب أيضًا.

لقد بحثت في بعض الدوافع الأساسية لهذه الوظائف ، ويبدو أننا بحاجة إلى القيام بكل التنظيم والتحويلات بأنفسنا ، لذلك إذا كان أي شخص آخر قد بذل الجهد بالفعل ، فمن أنا لأقول لا؟ ؛)

لا مشكلة ... يبدو أن الاختلاف الرئيسي كان مع تصريحات الهيكل ؛ نظرًا لأنه من المحتمل أن نصل إلى هذا أكثر في المستقبل ، فأنا أقوم ببعض إعادة البناء التي ستسمح لنا بمشاركة الكثير من توقيعات PInvoke. سأضيف وصفًا أكبر في العلاقات العامة الخاصة بي (اليوم أو غدًا ، بناءً على كيفية إجراء الاختبار) ولكني أضفت بشكل أساسي توقيعات PInvoke والتوقيعات لـ FreeBSD (بناءً على الرؤوس التي وجدتها عبر الإنترنت) ويتم تجميعها. لقد اختبرته على نظام التشغيل Mac ، لذلك _يجب_ (نظريًا ...) العمل على FreeBSD نظرًا لأنه مجرد تغيير إعلان هيكلي ، ولكن قد يختلف عدد الأميال الخاصة بك :). إذا لم يكن الأمر كذلك ، فستحصل على فئة DriveInfo و PInvokes 99٪ من الطريق هناك وستتطلب فقط بعض التغيير والتبديل بناءً على الفروق الدقيقة لـ FreeBSD.

أخبار ممتازةsokket. لقد أنشأت لك حسابًا على الجهاز الذي يستخدمه فريق المنفذ للتطوير ، وهو ذو أساس أوروبي ولكنه دائمًا قيد التشغيل ولديه الكثير من الذاكرة وقوة المعالجة. نأمل أن يساعد هذا في إزالة بعض الاحتكاك عند العمل مع FreeBSD.

# ssh [email protected]

تم تعطيل مصادقة كلمة المرور ، استخدم أحد المفاتيح الخاصة بك .

josteink راجع أيضًا المشكلة: https://github.com/dotnet/corefx/issues/815 (System.IO.FileSystem.DriveInfo لنظام التشغيل Mac / FreeBSD)

هل هناك أي تحديثات؟ هل قام أي شخص بتنفيذ التجميعات المتبقية على FreeBSD؟

لقد كنت مشغولاً بحضور طفلي الجديد ، ولم يكن لدي وقت لأي برمجة في أي مكان.

لقد اشتبهت في أن مثل هذه القضايا كانت كامنة وأعتقد أن هذا يؤكدها إلى حد ما.

بالنسبة للتجميعات التي لم يتم تنفيذها بعد ، قمت بربط "كيفية التنفيذ" - المشكلة في القائمة أعلاه. آمل أن يساعد ذلك في تنسيق الجهود لتنفيذ هذه التجمعات المتبقية.

يجب أن أعترف أنني كنت أعاني من صعوبات في تتبع ما فعلناه وأين ، لذا فهذه بالتأكيد خطوة جيدة. أحسنت :)

أين أجد ذلك؟ سيكون ممتنا للحصول على الجمعيات المتبقية
منفذ.

في 25/07/15 22:10 ، كتب Jan Henke:

بالنسبة للتجمعات التي لم يتم تنفيذها بعد ، قمت بربط "كيف
لتنفيذ "-إصدار في القائمة أعلاه. آمل أن يساعد ذلك في التنسيق
الجهد المبذول لتنفيذ هذه التجمعات المتبقية.

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/dotnet/corefx/issues/1626#issuecomment -124838781.

هذا التعليق هنا: https://github.com/dotnet/corefx/issues/1626#issuecomment -111800540

أنا الآن في انتظار الانتهاء من الحشوات الأصلية ، حيث يجب أن تتولى هذه معظم العمل لجعل هذه التجميعات تعمل على FreeBSD.

nguerrera سيكون رائعًا إذا كان بإمكانك إطلاعنا على التقدم. :)

تحديث:
أكد janhenke أنه مع دمج https://github.com/dotnet/corefx/pull/2974 ، تم دمج System.IO.Pipes على FreeBSD! :نظارة شمسيه:

تحديث:
تم إغلاق dotnet / corefx # 2527 ، وتم إنشاء System.IO.MemoryMappedFiles على FreeBSD.
شكرا janhenke للتأكيد!

بفضل نهج الحشوات ، يأتي الأمر فقط للتأكد من تجميع الحشوات على FreeBSD. لحسن الحظ ، هذا يجعل الحياة أسهل كثيرًا. :)

يجب أن تجلب لنا dotnet / corefx # 3257 كلاً من System.Diagnostic.Process و System.IO.FileSystem.Watcher ترك System.Net.NameResolution دون حل. (سوف أتحقق من التجميعين المذكورين بمجرد دمج العلاقات العامة والعمل على FreeBSD)

يجب أن تجلب لنا dotnet / corefx # 3471 System.Net.NameResolution وأن تكمل القائمة أعلاه.

تم دمج dotnet / corefx # 3471 للتو :)

sokket ، شكرا على التحديث. لقد قمت ببناء Master (f467911) على FreeBSD باستخدام هذا الدليل: https://gist.github.com/jasonwilliams200OK/6efa7907e66275df2d24. مانع الحالي هو https://github.com/dotnet/buildtools/issues/292 ، والذي تم إصلاحه في المنبع ولكن في انتظار طرح أدوات البناء التالية. :)

تحديث: أدوات buildtools جديدة مع الإصلاح لـ dotnet / buildtools # 292 قد هبطت في CoreFX master. السدادة التالية من buildtools هي https://github.com/dotnet/buildtools/issues/300 : أداة خاصة بنظام التشغيل مفقودة لتتمكن من إجراء الاختبارات.

janhenke ، لقد قمت System.Diagnostics.Process (# 2070) و System.IO.FileSystem.Watcher (# 2046) على أنه تم ؛ لكن لم يتم تنفيذها ولم يتم تجميعها على FreeBSD. هل تحققت بالفعل من القائمة عن طريق تجميع الكود المُدار؟

بناءً على تجربتي الأخيرة مع الالتزام 60c78da3c918b0d256cc1f878de06d351dbe3342 (انظر msbuild.log ) ، لا يتم تجميع التجميعات التالية:

• النظام ، التشخيص ، العملية
• System.Diagnostics.ProcessManager
• System.Diagnostics.ThreadInfo
• System.IO.FileSystemWatcher
• System.Net.SocketAddress _ (حسنًا ، تمت إضافة هذا مؤخرًا) _

بقدر ما أذكر ، فقد تحققت من تجميع الحشوات المرتبطة. نظرًا لأن الكود المُدار يجب أن يكون خاليًا من كود FreeBSD المحدد. يجب أن تكون تلك الحشوات التي ذكرتها قد تم التخلص منها مع العلاقات العامة المرتبطة أعلاه.
لكنني قمت أيضًا بتشغيل تجميع كامل بينهما. على الأقل تم تجميع System.Diagnostics.ThreadInfo و System.IO.FileSystemWatcher . لذلك يجب أن يكون هناك شيء ما قد تراجعت.

يجب أن تكون تلك الحشوات التي ذكرتها قد تم التخلص منها مع العلاقات العامة المرتبطة أعلاه.

في الواقع ، لا علاقة لـ PR https://github.com/dotnet/corefx/pull/3257 بـ shim. لا يزال هناك بعض كود PAL داخل المشاريع المدارة (الطريقة القديمة) ، لذلك يلزم إنشاء تجميعات مُدارة للتأكد تمامًا.

في الواقع ، لا علاقة لـ PR dotnet / corefx # 3257 بـ shim.

أنا أعترض. إنه يعيد بناء كود P / Invoke إلى System.Native shim. كما قمت بالتحرير أعلاه ، أتذكر على الأقل بعض التجمعات المجمعة فيما بينهما.

أنا أعترض

https://github.com/dotnet/corefx/pull/3257/files : راجع مثيلات .Unix.cs و .Linux.cs مقابل System.Diagnostics. . لاحظ أن .OSX.cs لم يمس.

إنه يعيد بناء كود P / Invoke إلى System.Native shim

نعم ، إنه يعيد بناء بعض المساعدين المشتركين تحت System.Native ، لكن ليس System.Diagnostics.* et al.

حتى عندما تكون هذه التجميعات هي فقط P / Invoking to System. * libs ، فقد يظل هناك عمل FreeBSD مطلوب لبعضها ، مثل System.Diagnostics.Process و System.IO.FileSystem.Watcher. إنهم يستخدمون وظائف خاصة بـ Linux و OS X ، ولا نخطط لمحاولة تجريد ذلك وراء الحشوات الأصلية. الهدف من الحشوات ليس أن ينتهي الأمر بثنائي واحد مُدار لـ Unix ، على الرغم من أن هذه خاصية رائعة جدًا عندما تأتي من العمل ؛ الهدف الأساسي هو تجنب الاختلافات ABI التي تسبب الهشاشة. أتوقع أن عددًا قليلاً من التجميعات ستستمر في الحصول على ثنائيات محددة لنظام التشغيل Linux / OS X ، حيث ستكون هناك حاجة أيضًا إلى برنامج FreeBSD الثنائي.

لمعلوماتك ، لا توجد تجميعات corefx تسمى System.Diagnostics.ProcessManager ،
System.Diagnostics.ThreadInfo ،
System.IO.FileSystemWatcher أو
System.Net.SocketAddress. هذه هي الأنواع في التجميعات الأخرى.

أتوقع أن عددًا قليلاً من التجميعات ستستمر في الحصول على ثنائيات محددة لنظام التشغيل Linux / OS X ، حيث ستكون هناك حاجة أيضًا إلى برنامج FreeBSD الثنائي.

هل يعني ذلك أنه عندما يصل Solaris و non-glibc (musl و μlibc) الذي يستهدف Linux مثل دعم Alpine ، سيكون لديهم ثنائيات منفصلة؟ ومن ثم تتطلب البنى المختلفة ARM و MIPS و RISC و SPARC وما إلى ذلك مستوى آخر من الفصل؟

ألن يكون من المنطقي دمجها مع واجهة POSIX / استدعاءات النظام قدر الإمكان وكشف الميزة عن الاختلافات باستخدام التكوينات (عبر CMake) لاستخدامها في نفس النظام الثنائي (ما لم تؤثر على حجم / أداء التجمعات بشكل كبير)؟ كما فهمت ، System.Native.so ثنائي له مساعد مشترك آخر محدد System.*.Native.so والذي يبدو كافيًا للامتثال لمبدأ فصل الاهتمامات. ولكن إذا تم تحويله إلى System.Net.Http.FreeBSD.ARM.Native.so أو System.Net.Http.Solaris.SPARC.so ، فلن يكون من الممكن إدارته تمامًا مع "الكثير من الأجزاء المتحركة" وما إلى ذلك.

لا توجد تجميعات corefx مسماة

نقطة جيدة. كنت في الواقع أذهب إلى حالات الفشل في سجلات msbuild وعدد ملفات .OSX.cs و .Linux.cs الملفات. :ابتسامة:

ألن يكون من المنطقي دمجها مع واجهة POSIX / استدعاءات النظام قدر الإمكان

نحن نفعل. كيف تقترح مشاهدة الملفات بشكل جيد عبر POSIX؟ كيف تقترح أن نقوم بمعالجة التعداد بشكل جيد عبر نظام POSIX؟

ولكن إذا تم تحويله إلى System.Net.Http.FreeBSD.ARM.Native.so أو System.Net.Http.Solaris.SPARC. لذلك ، فلن يكون من الممكن إدارته تمامًا باستخدام "عدد كبير جدًا من الأجزاء المتحركة" وما إلى ذلك.

أنا لا أفهم هذا. بيت القصيد من ملفات .so الأصلية هو أنك تحصل على ثنائيات أصلية مختلفة لكل نظام أساسي مستهدف ، لكن لم يتم تسميتها System.Whatever.Platform.ext ، فقط System.Whatever.ext ؛ يسمح للمترجم بأخذ نفس المنطق العام واستخدامه مع التعريفات الخاصة بتلك المنصة. يعمل هذا فقط عند وجود نفس الرموز على كل منصة ؛ لا يأخذ المترجم رمزًا مكتوبًا بطريقة سحرية لاستخدام inotify والسماح له بالعمل مع واجهة مشاهدة الملفات من نظام آخر. بشكل عام ، حاولنا جاهدين استخدام واجهات برمجة التطبيقات الموحدة حيث يكون ذلك منطقيًا ، ولكن بالنسبة للأماكن التي لا توجد فيها واجهات برمجة التطبيقات هذه أو غير موحدة بشكل جيد أو حيث توجد حلول خاصة بالنظام الأساسي ، استخدمنا النظام الأساسي الأفضل- حلول محددة ، على سبيل المثال استخدام procfs لتعداد العمليات على Linux ، واستخدام inotify لمشاهدة نظام الملفات على Linux ، وما إلى ذلك. ما إذا كان هذا المنطق الخاص بالمنصة يعمل في التعليمات البرمجية المدارة أو الأصلية لا يهم حقًا من سهولة النقل إلى منظور الأنظمة الأساسية الإضافية ، كما هو الحال عندما تأتي هذه الأنظمة الأساسية الجديدة ، إذا كانت واجهات برمجة التطبيقات الحالية تعمل ، فإن الحل الحالي يعمل كذلك ، وإذا لم يكن كذلك ، فأنت بحاجة إلى كتابة حل جديد لذلك النظام الأساسي. ولذا فقد حاولنا القيام بأكبر قدر ممكن في التعليمات البرمجية المُدارة ، وذلك باستخدام اللغة الأصلية ببساطة للحشوات 1: 1 التي تجعل هذا الرمز المُدار أكثر قابلية للنقل حيث تكون واجهات برمجة التطبيقات المستهدفة محمولة. لقد استخدمنا #ifdefs في الكود الأصلي لإخفاء التفاصيل الصغيرة ، حيث تكون واجهة برمجة التطبيقات هذه على أي منصة قريبة بما يكفي لواجهة برمجة التطبيقات على نظام أساسي آخر ، لكن هذا لا يمتد إلى الحلول الكاملة المختلفة تمامًا ؛ عند هذه النقطة ، يصبح التجريد هو واجهة برمجة التطبيقات المُدارة ونقوم بتنفيذ إدارة مختلفة لكل نظام.

إذا كشف FreeBSD عن inotify كما يفعل Linux أو إذا كان يعرض EventStream كما يفعل OS X ، فعندئذٍ عندما تكون واجهات برمجة تطبيقات نظام التشغيل هذه خلف الرقاقة ، يمكن بسهولة جعل الرقاقة تعمل مع FreeBSD ، ويمكن استخدام نفس النظام الثنائي المُدار على FreeBSD. إذا لم يكشف FreeBSD عن واجهات برمجة التطبيقات هذه ، فستحتاج إلى كتابة تنفيذ مخصص لـ System.IO.FileSystem.Watcher مع بعض حلول مراقبة الملفات المتوفرة على FreeBSD. تعليقات مماثلة لـ System.Diagnostics.Process. ما إذا كان رمز مشاهدة الملف في الرقاقة أم لا له تأثير ضئيل على ذلك.

الخطة هي أن يتم نقل كل واجهات برمجة التطبيقات الأصلية هذه في النهاية خلف الرقاقة. لكنها بعيدة عن أن تكون ذات أولوية ، لأنها ليست محمولة للغاية ، ولذا فقد رأينا نبدأ بواجهات برمجة التطبيقات من libc التي (أو من المفترض أن تكون) مكشوفة في كل مكان.

كيف تقترح مشاهدة الملفات بشكل جيد عبر POSIX؟

لا يمكننا القيام بكل ذلك POSIX ، نظرًا لأن inotify خاص بنظام Linux. تقدم FreeBSD / OSX تطبيقات منفصلة.

عرض:

من وجهة نظر توزيع الثنائيات الأصلية ، يجب أن يتلقى كل نظام تشغيل مجموعة متساوية من الثنائيات بنفس الأسماء ، ولكن وظائف مختلفة.

هنا هيكل مقترح:

# 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 ذات ملمس أصلي مستهلكة من المنطق في نظام ثنائي مشترك يديره Unix
• "قليلاً_تباعد_الوظائف" هي ذات ملمس أصلي تقريبًا وظائف 1: 1 مع بعض #ifdefs الأصلية التي يتم استهلاكها من المنطق في نظام ثنائي مشترك مُدار بنظام التشغيل Unix
• "painfully_diverged_watch_function" هي / سوف يتم دمج وظائف 1: 1 المستهلكة من المنطق في الثنائيات المُدارة الخاصة بالمنصة

الاختلاف الحقيقي هو ما إذا كانت الشفرة التي تنفذ منطق "التباعد المؤلم" تتم في C # أو C ++ ، وقد اخترنا C # وتم تنفيذها بالكامل بالفعل في C #. لم أر أي حجة مقنعة للسبب في أن إعادة كتابة كل شيء في C ++ ستكون خيارًا أكثر إقناعًا في مثل هذه الحالات.

@ jasonwilliams200OK مع تحديث اليوم إلى mono ، أقوم ببناء corefx على FreeBSD نفسها مرة أخرى. هناك الكثير من رسائل الخطأ الجديدة منذ آخر مرة قمت بإنشائها.
أتساءل عما إذا كان Interop.Libc سيختفي في النهاية؟

stephentoub كل شيء يتعلق
بالإضافة إلى ذلك ، أعتقد بشدة أننا بحاجة إلى تنفيذ عام لهذه "التعليمات البرمجية المُدارة المعتمدة على النظام الأساسي. حتى لو كانت تلقي فقط NotImplementedExcpetion. وبهذه الطريقة يمكنك نقل أسهل إلى الأنظمة الأساسية الجديدة ، إذا كان على الأقل يجمع كل شيء على الفور. كما أنه سيعطي فرصة لمحاولة الجري على منصة غير مدعومة على الأقل.
بشكل عام ، يكون من الأسهل كثيرًا إذا كان بإمكانك على الأقل التجميع بنجاح على الفور.

stephentoub ، آسف لأنني كنت

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 (لسبب ما لا أتذكره). :)

هنا msbuild.log للالتزام 2d36889:

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

/ سم مكعب: akoeplinger

@ jasonwilliams200OK لماذا معقدة للغاية. كل ما تحتاجه هو شرط "إن لم يكن Windows ، Linux ، OS X" في ملفات المشروع. لذلك إما تضمين مجموعة محددة من الملفات في النظام الأساسي أو الملفات العامة.

لا أعتقد أن حقيقة أن بعض التجميعات لا يمكنها البناء / العمل من أجل FreeBSD ومع ذلك يجب أن تكون مانعًا رئيسيًا لاختبار بقية المجموعات. ربما يجب علينا أن نجعلها فقط بحيث يتم تخطي الأشخاص الذين لديهم عمل معلق (FileSystemWatcher ، Process ، Networking) في الإنشاء والاختبار الذي يتم تشغيله على FreeBSD. ثم يمكننا أن نطرح هذه الأمور بشكل فردي مع وجود عملية لمنع الانحدار في ما يعمل بالفعل.

لا أعتقد أن حقيقة أن بعض التجميعات لا يمكنها البناء / العمل من أجل FreeBSD ومع ذلك يجب أن تكون مانعًا رئيسيًا لاختبار باقي المجموعات

متفق

ربما يجب علينا فقط القيام بذلك بحيث يتم تخطي الأشخاص الذين لديهم عمل معلق (FileSystemWatcher ، Process ، Networking) في الإنشاء والاختبار الذي يتم تشغيله على FreeBSD

أو على غرار ما اقترحه janhenke ، ما عليك سوى إنشاء

من خلال التغييرات الأخيرة في ellismg (# 3684) ، يمكنني تشغيل الاختبارات عن طريق تبسيط الطريقة السابقة (https://github.com/dotnet/coreclr/issues/1633#issuecomment-143669303):

• بعد https://gist.github.com/jasonwilliams200OK/6efa7907e66275df2d24 (خاصة الخطوة لبناء الحشوات الأصلية بشكل منفصل _after_ the build.sh exit with status 1) ، قم بتنزيل CoreCLR artifacts zip: cd /root; curl -o bins.zip "http://dotnet-ci.cloudapp.net/job/dotnet_coreclr/job/debug_freebsd/lastSuccessfulBuild/artifact/*zip*/archive.zip (لا تنسى الاقتباسات حول URL) ثم unzip bins.zip; chmod -R 0777 archive/; rm bins.zip; cd corefx .

(لا شيء مطلوب من جهاز Windows)

• شغّل الاختبار:

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

انها تقول:

فشل 40 اختبار (اختبارات)

لا أعتقد أن حقيقة أن بعض التجميعات لا يمكنها البناء / العمل من أجل FreeBSD ومع ذلك يجب أن تكون مانعًا رئيسيًا لاختبار بقية المجموعات.

يجب أن أتفق مع هذا. من الأفضل أن نبدأ في التحقق من جودة العمل الذي قمنا به ، بدلاً من انتظار اكتمال كل شيء قبل بدء الاختبار.

تقول: فشل 40 اختبار (اختبارات)

40 من كم؟ في أي ملعب كرة قدم نحن؟ :)

40 من كم؟ في أي ملعب كرة قدم نحن؟ :)

يتفوق عليّ أيضًا. يتم إنتاج الاختبارات من تجميعات الاختبار (dlls المُدارة) وإجمالي عدد الاختبارات غير مرئي.

الرقم الذي ينتجه البرنامج النصي في النهاية هو عدد تجميعات الاختبار التي فشلت. يجب أن تكتب xUnit عدد الاختبارات التي فشلت في كل مجموعة كجزء من تشغيلها. يجب أن تكون الأرقام أيضًا في ملفات XML التي تنتجها في كل مجلد تجميع اختبار.

يمكن أن يكون وقت التشغيل أيضًا في حالة تعطل وفي هذه الحالة قد لا يتم إنتاج سجلات لكل مجموعة اختبار.

@ jasonwilliams200OK هل تعرف ما إذا كان قد تم إحراز أي تقدم في قضية توقيع التجميع؟ أنا أضرب نفس الشيء على Ubuntu. إذا لم يعمل أحد على ذلك ، فربما يجب أن نفتح قضية منفصلة له.

naamunds ، تم إصلاحه على CoreFX master كجزء من https://github.com/dotnet/corefx/issues/3739.

تحديث - أجريت اليوم اختبارات على FreeBSD ، اجتاز الآلاف منهم ثم فشل البعض بسبب نقص واضح في System.Diagnostics.Process والأصدقاء snafu. بعد 40 دقيقة تقريبًا من التنفيذ الناجح ، تم تعليقه على اختبارات System.IO.FileSystem (لمدة 15 دقيقة تقريبًا قبل الضغط على Ctrl + C للإنهاء).

@ jasonwilliams200OK كيف تمكنت من تجميع corefx تحت freebsd؟ أنا عالق في أخطاء حول gssapi

@ sec ، في وقت كتابة هذه الملاحظات: https://gist.github.com/jasonwilliams200OK/6efa7907e66275df2d24 ، لم يكن GSSAPI مطلوبًا من CoreFX. ومع ذلك ، يبدو أنه تم نقل pkg مؤخرًا إلى FreeBSD: http://www.freshports.org/security/p5-GSSAPI. قد ترغب في تجربة pkg upgrade pkg && pkg update && pkg install p5-GSSAPI .

@ jasonwilliams200OK ، لقد حصلت بالفعل على هذا (إنه perl ext. راجع للشغل) كانت المشكلة مفقودة gssapi_ext.h. كانت الحيلة هي القيام بـ "pkg install krb5" - الآن مترجم أصلي.
لقد قمت بنسخها إلى وقت تشغيل coreclr ، ولكن ما زلت لا أستطيع تشغيل تطبيق ASP.NET Core :) يستمر القتال بعد ذلك.

ما هو الوضع الحالي لهذه المهمة؟ هل قائمة janhenke كاملة ودقيقة؟ هل كل العمل الذي يجب القيام به ، تم إنجازه؟ ثم يجب إغلاقه ، أليس كذلك؟

إذا كان الأمر كذلك ، فلماذا لا تزال لدينا هذه المهمة؟ https://github.com/dotnet/corefx/issues/2070

إذا كان لا يزال هناك عمل يتعين القيام به ، فهل يجب تسجيل إصدار جديد بناءً على الوضع الحالي؟

أعتقد أن هناك أيضًا هذا مطلوبًا - dotnet / corefx # 2046

هل يجب تسجيل إصدار جديد بناءً على الوضع الحالي؟

نعم: +1:

ناقشنا المنفذ المستند إلى المجتمع لـ FreeBSD مع wfurt (من فريق .NET Core) اللذين أبدى كلاهما اهتمامًا بالعمل.
إليك اقتراح خطة وضعناه معًا (نرحب بالملاحظات / الاقتراحات):

1. قم بإنشاء ثنائيات في CoreCLR و CoreFX repo تستهدف FreeBSD - استخدام الاختراقات أمر جيد
   
   
   
   • من الصعب موازاة ذلك ، وسيعملwfurt على ذلك
   
   
   • يمكن أن يكون الإصدار مزيجًا من تصميمات من منصات أخرى (Mac و Linux) تستهدف FreeBSD
   
   
   • سنحتاج إلى خطوات موثقة (على FreeBSD wiki) لإعادة إنتاج الإصدار باستخدام إصلاحات الأخطاء الخاصة بـ FreeBSD
   
   
2. تشغيل واستقرار اختبارات CoreCLR (باستخدام Corerun)
   
   
   
   • قد يتم إجراء الاختبارات على نظام أساسي آخر
   
   
   • الهدف: يوفر الجودة الأساسية لوقت التشغيل
   
   
3. تشغيل واستقرار اختبارات CoreFX (باستخدام Corerun)
   
   
   
   • قد يتم إجراء الاختبارات على نظام أساسي آخر
   
   
   • لاحظ أن هذا يتطلب xunit. نعتقد ، بناءً على تجربة النقل السابقة لدينا ، بمجرد الانتهاء من [2] ، سيعمل xunit.
   
   
   • يمكن أن يتوازى هذا نظريًا مع [2] - قد يتطلب اختصار xunit (على سبيل المثال ، إنشاء وصفة تنفيذ ثابتة على منصة أخرى)
   
   
4. مكدس كامل مبني على FreeBSD (باستخدام corerun كإقلاع من [1] - [3])
   
   
   
   • سنحتاج إلى جميع الأدوات (nuget و msbuild و roslyn) للعمل على تعزيز .NET Core
   
   
5. المثبتون (منافذ FreeBSD)
   
   
   
   • المرحلة الأولى: استخدام ثنائيات المنتج من خلاصات nuget
   
   
   • المرحلة الثانية: بناء المنتج من المصدر (ممنوع بناء على جهد المصدر)
   
   
   • يتطلب خبرة مجتمع FreeBSD وإرشادات حول التصميم
   
   
   • ملاحظة: يمكننا ربط حزم FreeBSD أيضًا من صفحات تنزيل .NET Core الرسمية كحزم دعم المجتمع
   
   
6. يعمل البناء والاختبار بانتظام على FreeBSD
   
   
   
   • الهدف: تأكد من أن التغييرات في .NET Core repos التي تكسر FreeBSD معروفة مبكرًا
   
   
   • مطلوب تصميم
   
   
   • يتطلب خبرة مجتمع FreeBSD وإرشادات حول التصميم
   
   

مبادئ العملية:

• التغييرات في [2] - [4] يجب أن تتم بشكل أساسي في CoreCLR / CoreFX repos (بسبب متطلبات توقيع CLA ، مراجعات الكود من خبراء / أعضاء فريق .NET Core. إلخ.)
• سنتتبع العمل رفيع المستوى بشأن هذه المسألة. سيتم تقديم أخطاء محددة كمشكلات منفصلة.

إذا كان أي شخص مهتمًا بالمساعدة ، فيرجى إخبارنا هنا. يمكننا بسهولة توزيع عناصر العمل من [2] و [3] أعلاه بمجرد أن نكون بعيدًا عن [1].

أحدث نسخة من الاقتراح في صدارة هذه القضية.

علامات أكثر الناس الذين أعربوا عن اهتمامهم على قائمة فري أحادية ( هذا الموضوع ):smortexradovanovic @ صدى-8-ERA

راجع للشغل: لا يمكنني العثور على حساب Mathieu Prevot GitHub - [تحديث] موجود في https://github.com/dotnet/corefx/issues/1626#issuecomment -330348424:mprevot

بالنسبة إلى NetBSD ، فقد افتقدنا كائنات ضبط البوزيكس القوية ، فهذه هي الميزة الوحيدة التي لا تزال مفقودة لإنتاج كائنات robus المسماة. يمكننا الآن تصحيح أخطاء التعليمات البرمجية المُدارة باستخدام LLDB / NetBSD .. إنه يعمل بشكل جيد مع الملفات الأساسية. في محاولاتي السابقة ماتنا بسبب عدم وجود هذه الميزة في LLDB (بدأت في نقل مصحح الأخطاء هذا إلى .NET).

سيساعد الحصول على دعم FreeBSD بشكل أفضل.

كانت هناك أيضًا مشكلات في الماضي تتعلق بنقص دعم الضيف الفائق لإرفاق برنامج بناء NetBSD بأجهزة CI والتحقق من التصحيحات ... لهذا قد أحتاج إلى مساعدة من MS. أتوقع أن هناك برنامجًا احتكاريًا مطلوبًا لتشغيله ، والذي لا أملكه ... قد أجد مطورًا للقيام بهذه المهمة إذا كان هناك اهتمام (استثمار) مشترك بين مؤسسة NetBSD و Microsoft.

أين نفتقد "كائنات المزامنة القوية"؟ هل هو جزء من .NET Core PAL؟

ما هو نظام CI الذي تشير إليه؟ لماذا يرتبط بجهد منفذ NET Core.

أين نفتقد "كائنات المزامنة القوية"؟

في نواة NetBSD (و libc / libpthread) ، يعد هذا جزءًا من CoreCLR. طورته FreeBSD في العامين الماضيين. قد يكون متاحًا في أحدث إصدار مستقر .. ولكن هناك حاجة للتحقق.

أرغب في إضافة هذه الميزة قبل إعادة تشغيل نقل .NET. (تم اكتشاف واجهة برمجة تطبيقات صغيرة مفقودة لتوجيه الشبكة .. لكني تخطيتها الآن).

هل هو جزء من .NET Core PAL؟

لا أتذكر الآن ، دون التحقق من الكود - إنها واجهة برمجة التطبيقات المستخدمة لتنفيذ .NET المسماة كائنات قوية (أو ربما semapthores).

ما هو نظام CI الذي تشير إليه؟

NetBSD.

لماذا يرتبط بجهد منفذ NET Core.

لقد كانت ميزة اختيارية في المرة الأخيرة التي نظرت فيها. قررت الحصول على ميزة التكافؤ على واجهات kernel والمرافق (مثل LLDB). فقط أسلوبي في العمل ، للحصول على كتل بناء وظيفية ثم بناء منزل لاحقًا. في مرحلة ما سنحتاجه على أي حال فلماذا لا نطوره دفعة واحدة. شكرا لتفهمك :)

ربما يمكنك فقط وضع علامة على مجموعة freebsd-dotnet على GH؟ إنه عضو هناك (أو يمكنك البحث عن اسم حسابه). بريده الإلكتروني هو [email protected]

[تحرير] حذف رسائل البريد الإلكتروني التي تم الاستماع إليها والرد السابق بواسطةkarelz

RussellHaley لا تتردد في وضع علامة على المجموعة الأكبر إذا كنت تعتقد أنها مناسبة. لم أتمكن من العثور على حساب Mathieu's GH عبر اسمه أو بريده الإلكتروني ، هذا ما قصدته أعلاه (راجع للشغل: لقد قمت بإرساله عبر البريد الإلكتروني مباشرة).

سوف أنظر في وضع العلامات على المجموعة.

هنا حساب ماتيو. ربما إعداد الخصوصية؟

https://github.com/mprevot

هتافات،

روس

يوم الإثنين 18 سبتمبر 2017 الساعة 1:01 مساءً ، كاريل زيكموند [email protected]
كتب:

RussellHaley https://github.com/russellhaley لا تتردد في وضع علامة على
مجموعة أكبر إذا كنت تعتقد أنه مناسب. لم أتمكن من العثور على Mathieu's GH
حساب عبر اسمه أو بريده الإلكتروني ، هذا ما قصدته أعلاه.

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/dotnet/corefx/issues/1626#issuecomment-330338996 ، أو كتم الصوت
الخيط
https://github.com/notifications/unsubscribe-auth/ACENF_N6mtOo3fptvku-LUMioNpZG7coks5sjswWgaJpZM4EPG-N
.

لا يمكنني رؤية أي مكان مذكور هنا ، ولكن ما هو الإصدار الأقل من FreeBSD الذي نستهدفه هنا (أفترض 10 على الأقل وما بعده ، ولكن ربما 9 أيضًا)؟
(أنا أيضًا مرتبك قليلاً بشأن المناقشة التي يجب أن تحدث في القائمة البريدية monofreebsd ، وماذا هنا؟)

حسنًا ، إذا كان فيدورا هو أي شيء يجب القيام به ، فإن MS ستدعم فقط الإصدارات المدعومة حاليًا ، أي 10.3 (10.4 قريبًا) و 11.1.

radovanovic لم يعد FreeBSD 9 مدعومًا ، 10 سوف EoL في أبريل 2018 ، 11 في 2021. من خبرتي لا ينبغي أن يكون هناك أي مشاكل في التجميع على 11 مقابل 10 (وحتى 9 إذا كنت تريد). تم تطوير FreeBSD مع مراعاة التوافق مع الإصدارات السابقة.

radovanovic أنا أيضًا مرتبك قليلاً ما هي المناقشة التي يجب أن تحدث على القائمة البريدية mono @ freebsd ، وماذا هنا؟

كنت أتوقع المناقشات الفنية وتنسيق العمل والحالة هنا لأن هذا جمهور أوسع من القائمة البريدية mono @ freebsd . OTOH لا نريد أن يكون لدينا عدد كبير من المناقشات العشوائية حول قضية واحدة ، لذلك قد نأخذ بعض مناقشات التصميم المحددة في قضايا منفصلة عن هذه المشكلة إذا زادت عن عدد معقول من الردود.

تمكنت أخيرًا من إجراء اختبارات corefx على FreeBSD 11.0 (بدون اختبارات Outerloop)
إجمالي النجاح: 144208
إجمالي الفاشلة: 2622
إجمالي تم تخطيه 207

سوف أقوم بتحديث https://github.com/dotnet/corefx/wiki/Building-.NET-Core--2.x-on-FreeBSD بالإرشادات. سوف أقوم بتقديم مشكلات محددة ووضع علامة عليها باستخدام os-freebsd و up-for-grab.
يمكن أن تبدأ المعركة على نطاق واسع. بحاجة لمتطوعين.

ونعم ، لقد تخطيت الخطوة الثانية المقترحة. سأعود إليها أيضًا.

مع بعض تغييرات العمل الجاري ، تبدو الإحصائيات الحالية كما يلي:
إجمالي النجاح: 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 لتتبع دعم الأكواب المكسورة.

تقدما كبيرا! يجب أن تكون إضافة NetBSD عند وجود دعم FreeBSD داخل الشجرة أمرًا بسيطًا.

wfurt الرجاء مشاركة عنوان البريد الإلكتروني ، وسوف أسقط بعض الأسطر.

تم دمج الدعم الأولي للفرع الرئيسي. يجب أن يعمل الإصدار كما هو موضح في صفحة WIKI.
أنا أتقدم ببطء على dotnet / corefx # 24386 لكن هذا لا ينبغي أن يعيق معظم المستخدمين.

هل يمكننا بالفعل تمهيد .NET على FreeBSD؟

لم أحاول لفترة من الوقت krytarowski @ كان هناك ضغط لتحديث الأدوات إلى الإصدار 2.0 وكنت أنتظر هذا الجهد لتحقيق الاستقرار. سأجربها مرة أخرى وسأقوم بنشر التحديث.

مرحبًا ، لقد تعثرت بسبب عدم تشغيل اختبارات CLR المُدارة. https://pastebin.com/B5KhtKX5

سيكون أي إدخال رائعًا لأن هذه كانت مشكلة لبعض الوقت. لقد واجهت مؤخرًا أيضًا فشلًا في الإنشاء في بناء corefx على Windows (رئيسي ، مراجعة Git 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 خطأ من نفس الطبيعة:

فشل - JIT / منهجية / casts / iface / _il_dbgiface2 / _il_dbgiface2.sh
بدء التنفيذ
/usr/home/russellh/Git/coreclr/bin/tests/Windows_NT.x64.Debug/Tests/coreoverlay/corerun _il_dbgiface2.exe
فشل coreclr_initialize - الحالة: 0x80004005
المتوقع: 100
العدد الفعلي: 255
التنفيذ النهائي - فشل

حسنًا ، وفقًا للمعلومات الممتازة جدًا من janvorli ، كنت أقوم بتشغيل جزء من

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

التصحيح هنا: https://pastebin.com/d5y9k1tw

إذا كان لديك تصحيح يعمل على إصلاح بنية معطلة ، فإنني أوصي بإرساله كطلب سحب حتى يتم إصلاحه للجميع :)

شكرا لك سأفعل. ما زلت أعمل على إجراء الاختبارات على الرغم من أنني لم أكن متأكدًا من سبب الخطأ التالي الليلة الماضية.

أفترض أن دعم Freebsd 11 "تثبيت pkg" لـ netcore 2.1 (بمجرد إصداره) لن يحدث ، أليس كذلك؟

TLDR ؛ تم إنجاز الكثير من العمل ، ولكن يجب أن يكون هناك شخص ما ليقودها إلى المنزل. كتابة المنفذ Makefile هو الجزء السهل.

تمكنتwfurt من الحصول على CLR و FX للبناء باستخدام Linux ولكن لم يتم اختبارها إلى حد كبير. لقد تمكنت من الحصول على الأجزاء "الأصلية" للبناء على FreeBSD ولكن تعثرت في الحصول على الأجزاء المدارة للبناء على Windows (لـ FreeBSD). كان الأمر برمته عبارة عن فوضى في نقل الملفات بين أنظمة التشغيل.

بشكل منفصل في القائمة البريدية [email protected] ، استوردdragonsa إصدارًا ثنائيًا من Dot Net Core 1 وجميع الأدوات (msbuild و nuget وما إلى ذلك) من MintOS باستخدام محاكاة Linux. لقد تمكنت من استخدام تصحيحاته وتشغيل بعض الأدوات ولكني لم أتمكن من بناء أي شيء. لست متأكدًا مما إذا كان قد تم تنفيذ هذه التصحيحات بعد ؛ كنت في منتصف مراجعتها وقمت بتغيير وظيفتي. ليس لدي أي شبكة DotNet في دوري الحالي وأعمل على القيام بأشياء أخرى في الوقت الحالي.

ما يعني كل ذلك؟ إذا تمكن شخص ما من التحقق من تصحيحات dragonsa ، [email protected] . https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/eresources-mail.html

russellhadley شكرا على الكتابة راسل.

أهلا،

بمناقشة هذا الأمر مع مطور .NET هنا ، فأنا على استعداد للمساعدة في تطوير حزمة / منفذ FreeBSD.

الكشف الكامل: أنا لست مطور .NET ولكنني على استعداد للعمل مع أي شخص لإدخال هذا في الشجرة.

~ cy

cschuber لقد كنت مشغولًا جدًا بحيث لا يمكنني أرسل الكثير من تصحيحات FreeBSD وتمكن من تشغيل Hello World منذ حوالي 3 سنوات ، فسيكون من الرائع لو تمكنا أخيرًا ترى هذا الشيء وهو يهبط بشكل صحيح. لديك دعمي الكامل :)

cschuber ، المشكلات النشطة الحالية هي https://github.com/dotnet/coreclr/issues/18067. يتم ترك هذه الميزات الأربع بشكل أساسي https://github.com/dotnet/corefx/issues؟q=is : open + label: os-freebsd + label : up-for-grabs + is: المسألة ، من بينها يبدو أن مراقب نظام الملفات الأكثر صعوبة / شاقة https://github.com/dotnet/corefx/issues/2046.

شكرا على العرض cschuber. لقد اقتربنا من نقطة يمكن أن يكون فيها ذلك ممكنًا.
لقد عملنا مؤخرًا مع mateusrodrigues للحصول على .net يعمل على FreeBSD وهو يحاول تشغيل PowerShell. قائمة @ kasper3 المرسلة هي في الأساس ميزات مفقودة. أعتقد أنه يمكننا طرح PNSP في الوقت الحالي. من أكثر القضايا الملحة المحتملة هي dotnet / corefx # 30698 و https://github.com/dotnet/coreclr/issues/18481. سيكون من الرائع أن يتمكن أي شخص من المجتمع من التعمق فيها. لم أجري الاختبارات مؤخرًا ، لكني أخشى أن يرتفع عدد حالات الفشل.
يجب أن نفتح قضية لكل مجموعة فاشلة جديدة.

أبدأ أيضًا في إصلاح بناء المصدر ولكن لا تزال هناك بعض التحديات المقبلة.
c # مترجم مكتوب في c #. يستخدم بناء. net الحالي الإصدار السابق من .net لإنتاج التجميعات المُدارة. يعتمد أيضًا على الحزم من Nuget.
في الوقت الحالي ، لدينا ما يكفي من bootstrap cli بحيث يمكننا بناء coreclr و corefx وعدد قليل من عمليات إعادة الشراء الأخرى على FreeBSD. لم أقم بتحديث تعليمات البناء حتى الآن لتعكس التغييرات 2.1 وبناء المصدر.

+1 مجرد ملاحظة لأقول إنني سعيد لأن هذا لا يزال يتمتع ببعض الزخم. من الصعب متابعة العديد من الأجزاء المتحركة ولكن يبدو أن الناس يحرزون تقدمًا. لقد أنشأت https://github.com/dotnet/coreclr/issues/6115 منذ فترة ولكن تم تعليق المشروع الذي كنت أعمل فيه. آمل حقًا أن يكون الأمر سهلاً مثل pkg install dotnet && dotnet build يوم واحد (بدون متوافق مع linux).

نتطلع أيضا لهذا

حصلنا على تصاميم يومية مستمرة الآن. يمكن للمرء الحصول على وقت التشغيل أو sdk هنا: https://dotnetcli.blob.core.windows.net/dotnet/Runtime/master/dotnet-runtime-latest-freebsd-x64.tar.gz و
https://dotnetcli.blob.core.windows.net/dotnet/Sdk/master/dotnet-sdk-latest-freebsd-x64.tar.gz

من الممكن أيضًا تجاوز الأهداف ، على سبيل المثال في Linux أو Windows ، يمكن للمرء أن يفعل dotnet publish -r freebsd-x64 وهذا من شأنه إنشاء تطبيق FreeBSD مستقل.

لا يزال غير مكتمل وغير مدعوم ولكن يجب أن يسهل على أي شخص المساهمة.
سيكون أمرًا رائعًا إذا كان بإمكان الأشخاص تجربته ، والإبلاغ عن المشكلات.
سيكون هذا أيضًا هو الوقت المناسب للدفع النهائي لسد فجوة الميزات وإصلاح الأخطاء.

نسخة إلى :

عمل رائع ، wfurt و @ bartonjs.

عندما اقترحت أول التزامات FreeBSD الخاصة بي منذ حوالي 2-3 سنوات ، لم أكن أصدق أننا سنصل إلى هنا ، لكنني أردت بالتأكيد المحاولة.

هذا بالتأكيد معلم كبير ونأمل أن يسهل على المساهمين الجدد المساعدة في إنهاء المنفذ.

شكراً جزيلاً لكل من ساعدنا في الوصول إلى هذا الحد 👍

تقدما كبيرا! ما زلت أقاتل مع toolchain (تم الانتهاء من معظم مشاريع LLVM إلى جانب LLDB و LLD) والمحاكاة الافتراضية بمساعدة الأجهزة لـ NetBSD (يبدأ Linux / BSD الآن في التمهيد حتى استثناء فادح VTx ، أنظمة تشغيل أبسط مثل FreeDOS تعمل بالفعل) .. لذلك سأستأنف نقل NetBSD الخاص بي ، آمل أن يكون ذلك عاجلاً وليس آجلاً. سيساعدك دعم FreeBSD الأفضل في سيرة ذاتية أسهل.

مذهل :)

نحن نتخلص من السكر لماذا قنابل انسيل ؟؟

krytarowski هل يمكنك تطوير الطرق التي يمكن أن يكون بها "دعم FreeBSD" أفضل؟

سيكون رائعًا إذا تمكن بعض معلمي FreeBSD من إلقاء نظرة على https://github.com/dotnet/coreclr/issues/22124 أتوقع إنشاء ثنائيات لـ 11 ليتم تشغيلها على 12 ولكن لا يبدو أن هذا هو الحال ؛ (
من السهل إعادة الإنتاج باستخدام تطبيق بسيط ويبدو أن الإصدار 12.0 يكسر شيئًا تعتمد عليه dotnet.

مرحبًا ، أنا لست خبيرًا ولكننا مررنا عبر انحدار مؤشر الترابط في 12-RELEASE في منفذ Lua53.
انظر هنا لمعرفة الخطأ الأصلي: https://bugs.freebsd.org/bugzilla/show_bug.cgi؟
وهنا لخلل النظام الأساسي الذي تم تحديده: https://bugs.freebsd.org/bugzilla/show_bug.cgi؟id=235211 (لاحظ أن خطأ النظام الأساسي يحدد الكود الذي يمكن استخدامه لإعادة إنتاج المشكلة للمقارنة).

الإصلاح الخاص بـ Lua هو الارتباط مقابل -pthread ، على الرغم من وجود متطلبات صفرية من Lua لـ -pthread.

RussellHaley شكرا. هذا يبدو وكأنه قيادة واعدة.

يسرني أني استطعت المساعدة. أود أن ألعب على طول لكني بالكاد أملك الساعات القليلة اللازمة لصيانة ميناء Lua. استمروا في العمل العظيم!

بصفتي الشخص الذي قام بإصلاح تطبيق FreeBSD للترابط في coreclr ، أعتقد أنه يتم استخدام pthreads بشكل متسق في كل مكان ، لأن هذا هو ما كان عليّ

بعد قولي هذا ، قد تكون هناك قطع أساسية لم أضطر إلى لمسها مطلقًا والتي تستخدم خيوطًا "عادية" ...

ربما يمكن لشخص آخر يعرف المزيد عن التنفيذ العام أن يتناغم؟ janvorli ؟

هذا يعمل على إصلاح المشكلة بالنسبة لي:

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

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

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

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

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

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

لم أجري أي اختبارات مكثفة ولكن على الأقل يمكنني تنفيذ dotnet مرة أخرى.

حسنًا ، أستطيع أن أرى أن ملف dotnet القابل للتنفيذ غير مرتبط بـ pthreads لأنظمة أخرى غير Linux.
https://github.com/dotnet/core-setup/blob/2ef0b64810530961f492c33d37fc7509128e0a9b/src/corehost/cli/exe.cmake#L59 -L61

هل هذا يعني أن الإجابة على إصلاح هذا بسيطة كما تبدو؟ أي بهذه البساطة؟ https://github.com/josteink/core-setup/commit/25657ba2e181cce401acd7f4bf9d27a08a668470

إذا كان الأمر كذلك ، فسأكون سعيدًا بجعلها علاقات عامة.

نعم أعتقد ذلك. كنت أنتظر joperator للتأكيد.
لست متأكدًا مما إذا كنا بحاجة إلى "dl" أيضًا ولكن يمكن حل ذلك عند إرسال PRjosteink

حق. خطأي. لذلك أكثر مثل هذا بعد ذلك: https://github.com/josteink/core-setup/commit/a08f38e25a98c25f59c8ed8c8567a0cb08b1c1c6

لقد أنشأت علاقات عامة لها. اسمحوا لي أن أعرف ما إذا كان يحتاج إلى أي تعديل: https://github.com/dotnet/core-setup/pull/5072

حق. خطأي. إذن أكثر مثل هذا: josteink / core-setup @ a08f38e

لقد أنشأت علاقات عامة لها. اسمحوا لي أن أعرف ما إذا كان يحتاج إلى أي تعديل: dotnet / core-setup # 5072

فقط لمعلوماتك ، يبدو أنه تم تصحيحه بالفعل في النظام الأساسي: https://reviews.freebsd.org/D18988

يبدو أن المشكلة الرئيسية في dotnet / coreclr # 22124 تم إصلاحهاwfurt.
لدي مشكلة فقط عند محاولة نشر تطبيق قائم بذاته على FreeBSD 12.0.

تمت إزالة حزم NuGet الرسمية freebsd-x64 منذ معاينة .NET Core 3.0 2 ولم نتمكن من نشر تطبيقات FreeBSD منذ ذلك الحين. هل هناك أي خطط لإعادة تمكينهم في 3.0؟

للأسف ، اضطررنا إلى إلغاء ترتيب أولويات عرض FreeBSD (لأسباب وصعوبات مختلفة في دعم Azure الشامل) ولن يكون ذلك أولوية في .NET Core 3.0.
نود أن نبقيها تعمل بشكل شبه في الحالة التي هي عليها الآن ، لكن ليس لدينا الكثير من الوقت للاستثمار الآن :(.

karelz شكرًا على ردك وأنا أفهم العمل ذي الأولوية لـ .NET Core 3.0. سأركز على إحضار تطبيقاتي باستخدام محاكاة FreeBSD Linux بعد ذلك. :)

@ hjc4869 أو يمكنك تجربة mono. IIRC ، سوف يدعم .NET Standard 3.0

أخطط لتجربته مرة أخرى ولكن كما ذكر

newsash Mono خيار مقبول بالنسبة لي. ومع ذلك ، وجدت صعوبة في إنشاء مشروعي مع إضافة أهداف أحادية إلى ملفات .NET Core csproj الحالية.

على جهاز Linux ، حاولت إضافة net472 إلى TargetFrameworks وتعيين متغير FrameworkPathOverride ولكن ذلك لم يعمل بشكل جيد. إذا كنت أستهلك واجهة برمجة تطبيقات يتم تنفيذها في كل من mono و .NET Core ، ولكن ليس .NET Framework ، فسوف يفشل في الإنشاء باستخدام mono. بالإضافة إلى ذلك ، على الرغم من أن mono يدعم .NET Standard 2.1 ، ما زلت لا أستطيع إضافة مرجع إلى .NET Standard 2.1 dlls في net472 csproj.

هل يجب علي إضافة csproj منفصل واستخدام mono msbuild بدلاً من استخدام أدوات dotnet ، أو هل لديك أي اقتراحات حول المشكلة؟

مجرد ملاحظة سريعة.

مع mono على وشك ابتلاع .NET 5 وفقًا للإعلان الأخير [1] ، أصبح توفير دعم لائق لـ FreeBSD أمرًا ملحًا.

أثبتت Mono أن لديها دعمًا جيدًا عبر الأنظمة الأساسية ويمكن بناؤها دون مشكلة من منافذ FreeBSD. تقوم العديد من المتاجر بتشغيل أحمال .net الخاصة بهم على FreeBSD نظرًا لأن نظام التشغيل هذا يحتوي على العديد من الميزات الفريدة. حتى الآن ، يعمل mono على سد الفجوة ولكن مع .NET 5 يبدو من المحتمل أنه في المستقبل القريب ، سيتم دمج mono في NET 5 وسيتم قطع مجتمع FreeBSD تمامًا عن نظام .NET.

يجب أن تتمتع Dotnet بدعم FreeBSD الناضج قبل حدوث ذلك بوقت طويل.

أعتقد أنه يجب على Microsoft دعم FreeBSD رسميًا في هذه المرحلة والتأكد من أن جميع أدوات dotnet مبنية على هذا النظام الأساسي.

وضع jasonpugsley التعليمات معًا https://github.com/jasonpugsley/core-sdk/wiki/.Net-Core-3.0.0-for-FreeBSD و joperator يحاول تشغيل بناء المصدر https: // github. كوم / دوت نت / مصدر-بناء / قضايا / 1139

لقد فشلنا آخر 30 اختبارًا لـ 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 في اختبارات System.Diagnostics.Tests.Process ، لذا فإن فشل اختبارات القفل يبدو أكبر فجوة متبقية. سيكون من الرائع أن يتمكن أي شخص من إلقاء نظرة على dotnet / corefx # 30899.

فقط أتساءل عما إذا كان هناك أي تحديثات على هذا أو إذا تم التخلي عنه؟

elfalem ، في هذه الأيام ، يتم تشغيل FreeBSD CI leg (التي يتم https://github.com/dotnet/dotnet-buildtools-prereqs-docker/ ، والتي تم تثبيت جميع المتطلبات المسبقة عليها. يمكننا استخدام نفس حاوية عامل الإرساء لنشر حزمة وقت التشغيل (بشكل أساسي tar.gz) ، محليًا أو جهاز بعيد. على سبيل المثال ، يمكننا إعداد GitHub Action في أحد فروع fork الخاصة بنا ، مثل: https://github.com/am11/runtime/blob/feature/freebsd/ci/.github/workflows/main.yml ، الذي يقوم بتحميل القطع الأثرية إلى إصدارات GitHub عند دفع العلامة https://github.com/am11/runtime/releases/tag/6.0.0-dev.freebsd.1. يحتوي أرشيف dotnet-runtime-6.0.0-dev-freebsd-x64.tar.gz في هذه الحالة على وحدات بت كافية لتشغيل تطبيق dotnet منشور (من نظام Linux / mac مختلف يحتوي على dotnet SDK). لقد اختبرته من خلال إنشاء 12.2 VM جديد (متشرد) ، واستخراج ونسخ تطبيق منشور من mac إلى VM ، وقد نجح:

#!/usr/bin/env tcsh

$ sudo pkg install libunwind icu libinotify

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

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

$ dotnet /vagrant/MyPublishedApp.dll
Hello World!

أعتقد أن Thefrank كان يبحث في إنشاء حزمة FreeBSD Ports مناسبة في مرحلة ما.

فقط أتساءل عما إذا كان هناك أي تحديثات على هذا أو إذا تم التخلي عنه؟

قد ترغب في إلقاء نظرة على https://github.com/dotnet/source-build/issues/1139
لم أحاول مؤخرًا بينما أنتظر نهائي dotNET5 ، ولكن ، منذ بضعة أشهر ، لا يمكن إنشاء وقت تشغيل FreeBSD إلا كتجميع متقاطع على Linux. تطلب ASPNet و SDK أيضًا تجميعًا متقاطعًا من Linux ولكن تم إنشاؤه فقط إذا كانت النجوم محاذاة (تحديثات آركيد أو بعض الروبوتات الآلية الأخرى لم تكسر التبعية)

تحرير: ونشر @ am11 كتابة أفضل أثناء
Edit2: نسيت علامات الترقيم ويبدو أنه تم حذفها قبل يومين. أعتقد أنني يجب أن أبدأ العمل على ذلك أو شيء من هذا القبيل

بصرف النظر عن كل ما سبق ، قمت بإنشاء مشروع FreeBSD في https://github.com/dotnet/runtimelab/ وأنا أتقدم ببطء في إنشاء الحزم ونشرها. الهدف هو إنشاء ونشر ما يكفي لتشغيل التطبيق على FreeBSD والحصول على بذرة لبناء المصدر.

ظننت أنني سأكتب تحديثًا سريعًا. لقد حصلت أخيرًا على جميع الكواكب في محاذاة لبناء 5.0.0 RTM على FreeBSD. لم أستمر في العمل منذ Preview3 واستغرق الأمر بعض الوقت (والعديد من محاولات الإنشاء) للعثور على المجموعة الصحيحة من البنيات المتوافقة للحصول على الإصدار 5.0 بنجاح.
لقد تمكنت من إنشاء PowerShell 7.1.0 مع عدد قليل من الاختراقات المدهشة ، إلا أنه يعمل على الرغم من أنني لم أختبره جيدًا ولكن يبدو أنه اختبار جيد لـ SDK.
لقد قمت للتو ببناء AspNetCore ولكني لم أختبره على الإطلاق.

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

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

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

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

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

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

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

$ dotnet run
Hello World!
$

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

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

PS /tmp/powershell> $PSVersionTable

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

PS /tmp/powershell> Get-Host

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


PS /tmp/powershell>

المشكلة الوحيدة في القيام بهذا العمل يدويًا (على سبيل المثال خارج نظام CI) هي المشكلة الناتجة عن تغيير التغييرات التي تتطلب بنية معينة لتكون متاحة للاستخدام التالي للبنية. لا يحدث ذلك كثيرًا ولكنه يتطلب الكثير من التجربة والخطأ للعثور على الالتزام الصحيح. يجب أن يؤدي امتلاك Linux cross-build في نظام CI إلى إصلاح ذلك ولكني لم ألقي نظرة على ذلك بعد. لا يزال من الجيد معرفة أنه يمكنني إنشاء SDK كاملة ثم استخدام SDK لإنشاء شيء آخر.

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

هذا تقدم جيدjasonpugsley. أحاول العثور على إجابة أفضل للبناء لكنني لم أتمكن من تخصيص أي جزء من الوقت في الشهر الماضي ؛ (
هل أعطاك PowerShell أي حزن بسبب معلومات المصطلحات أو هل قمت بنسخ تعريف المحطة الطرفية من مكان آخر؟

لقد حصلت على تعريف المحطة الطرفية من جهاز Mac الخاص بي حيث كنت من ssh'd.

jasonpugsley أنت متقدم أمامي. الأساسية و sdk بناء من لينكس عبر freebsd. تعمل بشكل جيد من الاختبار المحدود الذي تم إجراؤه. لا وقت التشغيل ولا sdk crossbuilts قادران على البناء على freebsd نفسها (تستخدم لينكس و freebsd llvm9 و clang9).
ld: error: /root/runtime/artifacts/obj/coreclr/FreeBSD.x64.Release/src/dlls/dbgshim/dbgshim.exports:1: unknown directive: V1.0
سيء الأمر أكثر قليلاً إذا كان لدي المزيد من الوقت في نهاية هذا الأسبوع وأرى أيضًا ما إذا كان بإمكاني على الأقل الحصول على aspnetcore مبنية على لينكس من أجل freebsd

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 ؟
إذا كنت تحاول تجميع SDK 5x على Ubuntu 18 أو 20 ، فقد ترغب في تطبيق هذا التصحيح https://github.com/dotnet/sdk/commit/80e42f16422352f725d78be72071781d8365a238 (إنه في الفرع الرئيسي).

أنا حقا بحاجة إلى التوقف عن نشر المشاركات عندما نصف نائم.
اكتمال بناء وقت التشغيل و sdk على لينكس.
تعمل هذه الثنائيات على freebsd (dotnet --info ، وحدة تحكم جديدة ، وتشغيل)
هذه الثنائيات غير قادرة على إنشاء وقت تشغيل أو sdk من المصدر على freebsd

آه طيب. لم أحاول وضع ثنائيات stage0 في dogfoding لإعادة إنشاء وقت التشغيل على FreeBSD كـ HostOS.

ld: خطأ: /root/runtime/artifacts/obj/coreclr/FreeBSD.x64.Release/src/dlls/dbgshim/dbgshim. الصادرات: 1 : توجيه غير معروف: V1.0

قد يكون من المفيد الإبلاغ عن هذه المشكلة بشكل منفصل. من المحتمل أن تكون هناك طرق متعددة لإصلاحها ، ولكن هل يحدث هذا التصحيح أي فرق:

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

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

 function(generate_exports_file_prefix inputFilename outputFilename prefix)

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

هل هذا التصحيح يحدث أي فرق

أتوقع أن تتبع FreeBSD لينكس فيما يتعلق بنصوص إصدار الرموز ، وليس داروين. IMO من المرجح أن المشكلة تكمن في أن هناك شيئًا محددًا لـ GNU-awk في Geneversionscript.awk

التصحيح غير الخطأ:
ld: error: /root/runtime/artifacts/obj/coreclr/FreeBSD.x64.Release/src/dlls/dbgshim/dbgshim.exports:1: unknown directive: _CreateProcessForLaunch
إذا كانت مشكلة إصدار awk:

awk --version
awk version 20121220 (FreeBSD)

إذا كان من السهل التجربة ، فهل يمكنك محاولة تثبيت حزمة gawk وتغيير الاستدعاء في ملفات CMake إلى gawk؟

عادت التصحيح. تثبيت gawk pkg.
كسول جدًا لمعرفة كيفية تمرير البرنامج النصي build.sh على cmake args لأنه لا معنى له على الفور ، لذلك قمت فقط بربط gawk-> awk.
نفس الخطأ الأصلي
ld: error: /root/runtime/artifacts/obj/coreclr/FreeBSD.x64.Release/src/dlls/dbgshim/dbgshim.exports:1: unknown directive: V1.0

تعديل متأخر: يبدو أن الثنائيات على نظام التشغيل Linux لم يتم إنشاؤها بشكل صحيح:

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

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

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

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

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

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

بشكل أساسي ، قد يتسبب RID: osx-x64 حدوث بعض المشكلات

بشكل أساسي ، قد يتسبب RID: osx-x64 حدوث بعض المشكلات

يتم عرض RID بواسطة SDK بعد بعض قرارات الأنظمة المدعومة مقابل الأنظمة الأساسية غير المدعومة. ليس له أي تأثير على تنفيذ التطبيق. RID الحقيقي الذي اكتشفه وقت التشغيل صحيح ، وإلا فلن يتم تنفيذ التطبيقات (مثل dotnet(1) ) بشكل صحيح.
c# using System; using System.Runtime.InteropServices; class Program { static void Main() => Console.WriteLine("Real RID: {0}", RuntimeInformation.RuntimeIdentifier); }
طباعة Real RID: freebsd.12-x64 على صندوقي.

تم فتح # 45663 لتتبع إصدار ld. كنت قادرًا على التكاثر أيضًا.

@ Thefrank بخصوص الخطأ ld ، جرب هذا:

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

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

سيؤدي ذلك إلى تنشيط عبارة 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()

لأكون صريحًا تمامًا ، لست خبيرًا في الروابط ، لذا أثناء عمل هذا ، لم أبحث بشكل أعمق لمعرفة ما هو مطلوب بالفعل / أساسي للرنجة على FreeBSD.

آه ، تهاجم مشكلة وكيل المستخدم الرابط مرة أخرى. تتضمن سلسلة إصدار LLD (compatible with GNU linkers) في محاولة للذهاب إلى مسار GNU ld لتكوين الاختبارات ولكن من الواضح أنها ليست ذكية بما يكفي لهذه الحالة :)

تبدو المطابقة على LLD جيدة هنا حتى إذا تم تسمية علامة LD_GNU بشكل خاطئ إلى حد ما.

نعم انها تحتاج الى مزيد من العمل. اسم العلم محير الآن. من فضلك لا يحاول أي شخص ارتكاب هذا كما هو.

من: Ed Maste [email protected]
تاريخ الإرسال: الاثنين ، 7 ديسمبر 2020 ، الساعة 10:26:48 صباحًا
إلى: dotnet / runtime
نسخة إلى: Jason Pugsley [email protected] ؛ أذكر [email protected]
الموضوع: Re: [dotnet / runtime] دعم FreeBSD (# 14537)

آه ، تهاجم مشكلة وكيل المستخدم الرابط مرة أخرى. تتضمن سلسلة إصدار LLD (متوافقة مع روابط GNU) في محاولة للذهاب إلى مسار GNU ld لتكوين الاختبارات ولكن من الواضح أنها ليست ذكية بما يكفي لهذه الحالة :)

تبدو المطابقة على LLD جيدة هنا حتى إذا تم تسمية علامة LD_GNU بشكل خاطئ إلى حد ما.

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذه الرسالة الإلكترونية مباشرةً ، أو قم بعرضها على GitHub https://github.com/dotnet/runtime/issues/14537#issuecomment-739583816 ، أو قم بإلغاء الاشتراك https://github.com/notifications/unsubscribe-auth/AECFDEXKTDFRAX4ZEE6VXZTSTQHLRANCNFSM4

اخترت استخدام 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]

اكتملت المجموعة الفرعية "أحادية" والمجموعة الفرعية "libs" بدون أخطاء

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):
علمت أنني نسيت أن أفعل شيئًا قبل أيام قليلة! يجب أن يكون هذا ممتعًا

تحرير: بدون crossgen (ويعرف أيضًا باسم النصف الثاني فقط)

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

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

Time Elapsed 00:12:05.56

تحرير التعديل الأخير في هذا المنشور أقسم:
أعلم أن الاختبارات يمكن أن تستغرق بعض الوقت وهي تقول اختبار تشغيل طويل ولكن هذا يخرج عن السيطرة في اختبار واحد
System.Net.HttpListener.Tests: [Long Running Test] 'System.Net.Tests.HttpListenerResponseTests.AddLongHeader_DoesNotThrow', Elapsed: 00:36:20

قتل الاختبار بعد الانتظار لمدة ساعتين لا تزال هناك إخفاقات في الاختبارات الأخرى

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