Runtime: تمكين Linux ARM32 لـ .NET Core

CCschellap ramaragjanvorli _

كما ذكرت في المناقشة في dotnet / core-setup # 724 ، أعتقد أننا يجب أن نكون متسقين في الطريقة التي نتبادل بها البناء على اتفاقيات إعادة الشراء الخاصة بنا. هذا يعني استخدام rootf والقيام بالبناء المتقاطع باستخدام clang وليس GCC. بنفس الطريقة التي نقوم بها في CoreCLR و CoreFX.
آمل أن نتمكن من إعادة استخدام المنطق من build.sh في CoreCLR هنا.

hqueue @ hseok-oh هل Ubuntu 14.04 هدف مقصود لـ Arm32؟

@ gkhanna79 AFAIK الافتراضي ريد هو ubuntu.14.04-arm لـ coreclr ARM والجذور الافتراضية لـ ARM مضمونة وهو ubuntu 14.04.

@ HQueue @ gkhanna79 Raspberrypi2 تستخدم Ubuntu 14.04. (ولكن لم تعد مدعومة)
https://wiki.ubuntu.com/ARM/RaspberryPi

@ hseok-oh إذا لم يتم صيانة Ubuntu 14.04 ودعمه ، فهل هناك سبب محدد لدعمه لنظام Linux Arm32؟ إذا لم يكن الأمر كذلك ، فسيتم تبسيط مجموعة من الأشياء (على سبيل المثال ، libcoreclrtraceptprovider.so يبني جيدًا لـ 16.04 ولكنه يحتاج إلى عمل إضافي لـ 14.04).

ما رأيك؟

AFAIK الافتراضي ريد هو ubuntu.14.04-arm لـ coreclr ARM و rootfs الافتراضي لـ ARM مضمون وهو ubuntu 14.04

لا أعرف من اختار تلك الافتراضات أو لماذا. هل يمكن أن يكون السبب في أن Tizen OS يعتمد على Ubuntu 14.04؟ هل نبني libcoreclrtraceptprovider.so لـ Tizen؟

kouvel هذه هي مشكلة قائمة العمل الرئيسية لـ Linux Arm32.

CCschellap

AFAIK الافتراضي ريد هو ubuntu.14.04-arm لـ coreclr ARM و rootfs الافتراضي لـ ARM مضمون وهو ubuntu 14.04

لا أعرف من اختار تلك الافتراضات أو لماذا. هل يمكن أن يكون السبب في أن Tizen OS يعتمد على Ubuntu 14.04؟ هل نبني libcoreclrtraceptprovider.so لـ Tizen؟

@ gkhanna79
لا أعتقد أنه مرتبط بنظام التشغيل Tizen OS.
سيكون التفسير الأكثر احتمالاً هو أن ubuntu 14.04 تم اختياره بسبب الأجهزة (مثل ARM Emulator و Raspberry pi 2 وما إلى ذلك) التي تم استخدامها لإحضار CoreCLR ARM.
يرجى مراجعة https://github.com/dotnet/coreclr/issues/3805 لمحاكي ARM الذي يتم استخدامه في المرحلة المبكرة جدًا من إظهار CoreCLR ARM32.

شكرا على الشرح @ hqueue. في الوقت الحالي ، يمكننا الاستمرار في البناء لكل من 14.04 و 16.04 ونرى إلى أي مدى سنحتاج إلى تطبيق 14.04.

فيما يتعلق بالمحاكي ، لاحظت أنه في CoreCLR repo ، نقوم بتشغيل المحاكي وإعداد ملفات rootf بداخله ثم تنفيذ الإنشاء. هذا يختلف عن تعليمات الإنشاء التي لدينا على https://github.com/dotnet/coreclr/blob/master/Documentation/building/cross-building.md حيث تتكون من خطوتين:

1. بناء جذور للعمارة
2. تنفيذ بناء متقاطع من الريبو

نحن نسعى جاهدين للتأكد من أن CI يبني بنفس الطريقة التي يبني بها أي مطور. نظرًا لأن الخطوات المذكورة أعلاه هي الطريقة التي يُتوقع من أي مطور في المجتمع أن يبنيها لـ Arm32 ، ما رأيك في تحديث البرنامج النصي CI للقيام بذلك وعدم الاعتماد على المحاكي ليكون موجودًا لتنفيذ الإنشاء؟

ثانيًا ، يجب أن يُطلب من المحاكي فقط نشر الثنائيات وتنفيذ الاختبارات. لقد لاحظت أننا نجري فقط 22 اختبارًا داخل المحاكي ، على الرغم من أن الريبو به 11 ألف + اختبار. هل تضيف هذه الاختبارات الـ 22 أي قيمة من منظور CI (على سبيل المثال ، يوجد هنا سجل علاقات عامة حديثة يعرض 22 اختبارًا تم إجراؤها - https://ci.dot.net/job/dotnet_coreclr/job/master/job/arm_emulator_cross_debug_ubuntu_prtest / 1080 / consoleFull) لأنها لا يبدو أنها تغطي السيناريوهات الرئيسية حيث قد يتم تقديم الفواصل؟

@ gkhanna79 بالنسبة للسؤال الأول ، سأتصل بـsjsinjuwateret ، لأنني لست على دراية بأحدث ARM CI.

sjsinju wateret هل يمكنك من فضلك الإجابة على السؤال الأول أعلاه بخصوص محاكي CI و ARM؟

بالنسبة للثاني ، أعتقد أيضًا أن الاختبارات ليست كافية لتغطية مفتاح sccenarios. سوف ننظر فيها.

@ gkhanna79
يبني CI بنفس الطريقة التي يقوم بها أي مطورين. يمكنك التحقق من arm32_ci_script.sh # L227 . المحاكي هو فقط لإجراء الاختبارات. وبالطبع ، ما زلنا بحاجة إلى جذور جذرية مسبقة البناء لبناء متقاطع.

هناك شيء آخر قد يكون مربكًا وهو أن CI لديها جذور جذرية للأذرع فقط والتي لا يمكن إنشاؤها بواسطة "أي مطورين". هناك عملي على CoreFX لتمكين arm-hardfp (ubuntu 14.04). بعد الانتهاء من ذلك ، سأقوم بتطبيقه على CoreCLR أيضًا.

@ gkhanna79 لم أجد مكان بناء libuv.so. هل يمكن أن تعطيني نصيحة؟

jyoungyun لست متأكدًا مما إذا كانت هذه هي الطريقة التي تم بها إنشاء libuv لـ .NET ، ولكن بالنسبة إلى raspberry pi ، كانت التعليمات حتى الآن لتنزيله من مشروع libuv وتجميعه:

راجع هذه التعليقات من leemgs المتعلقة بـ dotnet / coreclr # 6321

rpi2@arm# sudo apt-get install gyp
rpi2@arm# wget http://dist.libuv.org/dist/v1.0.0-rc1/libuv-v1.0.0-rc1.tar.gz 
(The latest version is v1.9.1: http://dist.libuv.org/dist/v1.9.1/libuv-v1.9.1.tar.gz)
rpi2@arm# tar -xvf libuv-v1.0.0-rc1.tar.gz
rpi2@arm# cd libuv-v1.0.0-rc1/
rpi2@arm# ./gyp_uv.py -f make -Duv_library=shared_library
rpi2@arm# make -C out
rpi2@arm# sudo cp out/Debug/lib.target/libuv.so /usr/lib/libuv.so.1.0.0-rc1
rpi2@arm# sudo ln -s libuv.so.1.0.0-rc1 /usr/lib/libuv.so.1

لقد نجح ذلك بالنسبة لي في تشغيل Kestrel وتشغيله على Raspberry Pi ؛ لكن لاحظ أن الإصدارات الأحدث من libuv متاحة الآن على http://dist.libuv.org/dist/

يبني CI بنفس الطريقة التي يقوم بها أي مطورين.

wateret وجهة نظري هي أنه يجب علينا فصل البناء المتقاطع في CI عن المحاكي. الفارق البسيط هو أنه في CI ، نقوم بإعداد rootfs من المحاكي ثم نقوم بإجراء بناء متقاطع بينما لا يقوم المطور العادي بذلك. اقتراحي هو إصلاح البرنامج النصي للقيام بما يلي:

1) بدون المحاكي ، قم بتنفيذ البناء المتقاطع (على سبيل المثال ، ذراع cross / build-rootfs.sh)
2) قم بتحميل المحاكي لإجراء الاختبارات فقط. وبالتالي ، إذا قررنا أنه قد لا تكون هناك حاجة إلى المحاكي للاختبار لسبب ما ، فسيستمر البناء المتقاطع في العمل كما هو متوقع.

hqueue هل وجدت شيئًا مثيرًا للاهتمام حول إجراء الاختبارات الـ 22 في CI؟

qmfrederik شكرا لك على إجابتك. ما تتحدث عنه هو كيفية تنزيل libuv.so مباشرة. لكني أريد أن أعرف مكان إنشاء libuv .nupkg.

@ gkhanna79

نقوم بإعداد rootfs من المحاكي ثم نقوم بإجراء بناء متقاطع بينما لن يقوم المطور العادي بذلك.

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

بالنسبة لأول اقتراح اقترحته ، أنا أتفق معك بشكل أساسي. ومع ذلك ، يستغرق إنشاء rootfs وقتًا طويلاً باستخدام build-rootfs.sh . بقدر ما أتذكر ، استغرق الأمر ساعة إلى ساعتين على جهاز Linux الخاص بي. لست متأكدًا مما إذا كان ذلك مقبولًا.
بالنسبة للثاني ، يتم تحميل المحاكي فقط لإجراء الاختبارات بالفعل. لا يعمل Build على المحاكي. عبر يبني.

هل وجدت أي شيء مثير للاهتمام حول إجراء 22 اختبارًا في CI؟

@ gkhanna79 هذه الاختبارات الـ 22 عبارة عن أبرز المساهمين حيث لاحظنا الانحدار بشكل متكرر عند البحث عن CoreCLR لنظام Linux ARM32. لذلك فإن تغطية 22 اختبارًا لا تغطي الكود الذي لم يتم تعديله بشكل متكرر. ومع ذلك ، لا يمكننا تشغيل جميع المساهمين الأساسيين (11K +) باستخدام محاكي ARM لأن الأمر استغرق وقتًا طويلاً جدًا وواجهنا مهلة في بيئة CI.

أعتقد أيضًا أننا بحاجة إلى المزيد من أبرز المساهمين لـ CI ، لكننا غير متأكدين من كيفية اختيار المرشحين. هل يمكنك اقتراح أي خيارات؟

cc: jyoungyun

jyoungyun أعتقد أن حزمة libuv NuGet موجودة هنا: https://github.com/aspnet/libuv-package ؟

qmfrederik شكرا لك! سوف أتحقق من هذا المستودع.

أخيرًا ، نجحت في الحصول على ملف dotnet-ubuntu-arm.1.2.0-beta-001206-00.tar.gz ، والذي أكد أنه يعمل جيدًا على Raspberry PI2. لقد قمت ببناء مستودع الإعداد الأساسي باستخدام مصدر nupkg المحلي وهذه هي النتائج التي تم إنشاؤها من CoreCLR و CoreFX (بما في ذلك https://github.com/dotnet/corefx/pull/14655 patch). إذا تم تحميل CoreCLR و CoreFX nupkgs في NugetServer أو في أي مكان ، فيمكننا إنشاء .NET Core Runtime لـ Ubuntu ARM. لقد اختبرت فقط على Ubuntu 14.04 وسأجري الاختبار في 16.04 لاحقًا.

jyoung@DXL-Workstation:~/git/dotnet/core-setup-jy/artifacts/ubuntu.14.04-arm/packages$ ls
total 33M
-rwxrw---- 1 jyoung jyoung  28K Dec 21 18:18 dotnet-deb-tool.1.0.1-t-beta-001206.nupkg
-rw-rw---- 1 jyoung jyoung 226K Dec 21 18:19 dotnet-hostfxr-ubuntu-arm.1.2.0-beta-001206-00.tar.gz
-rw-rw---- 1 jyoung jyoung  17M Dec 21 18:19 dotnet-sharedframework-ubuntu-arm.1.2.0-beta-001206-00.tar.gz
-rw-rw---- 1 jyoung jyoung  17M Dec 21 18:19 dotnet-ubuntu-arm.1.2.0-beta-001206-00.tar.gz
drwxrwx--- 2 jyoung jyoung 4.0K Dec 21 17:04 intermediate

pi<strong i="10">@raspberrypi</strong>:~/Downloads/24919/shared/Microsoft.NETCore.App/1.2.0-beta-001206-00 $ ./dotnet hello.exe 
Hello World

مدهش! إذا كان هناك أي طريقة لمشاركة حزم / كرات القطران NuGet ، فسأكون سعيدًا بتجربتها على RPi 2 & 3 ، ومعرفة المدى الذي وصلت إليه مع منتجنا المستند إلى .NET Core :)

نجحت في الحصول على ملف dotnet-ubuntu-arm.1.2.0-beta-001206-00.tar.gz

هذا خبر ممتازjyoungyun! شكرا لكم جميعا لقيادة هذا من خلال :)

تأتي حزمة LibUV من مستودع ASP.NET. Eilon هل يمكنك أن تنصحني من الريبو الذي يجب تجنيده لبناء هذه الحزمة؟

إذا تم تحميل CoreCLR و CoreFX nupkgs في NugetServer أو في أي مكان

هذا هو العمل الذي أتبعه لإنجازه كجزء من دعم بناء خط أنابيب E2E عبر مستودعات NET Core الثلاثة (CoreCLR و CoreFX و Core-Setup).

تضمين التغريدة

بقدر ما أتذكر ، استغرق الأمر ساعة إلى ساعتين على جهاز Linux الخاص بي

موضوع مثير للاهتمام. بالنسبة لي ، يستغرق إنشاء rootfs الجديدة حوالي 7 دقائق أو نحو ذلك على محرك أقراص USB 3.0 SSD الخاص بي لكل من تصميمات Trusty و Xenial. كل شيء آخر هو تكلفة بناء متقاطع منتظم من هناك. ومن ثم ، سؤالي حول سبب حاجتنا إلى التقاط rootfs من المحاكي وليس مجرد جلبه في كل مرة. بناءً على ذلك ، لتمكين إنشاء CI لـ Ubuntu 16.04 arm ، هل تخطط لإضافة محاكي آخر يحتوي على rootfs؟

تضمين التغريدة

هل يمكنك اقتراح أي خيارات؟

هل لديك أي أتمتة حول الاختبارات على المخلفات الخطرة الحقيقية؟ تفكيري الحالي هو تقييم القيام بذلك لصالح المحاكي في المستقبل المنظور.

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

الكود المصدري libuv هو طرف ثالث وهو هنا: https://github.com/libuv/libuv

عملية بناء فريق ASP.NET لتجميع libuv موجودة في الريبو الخاص بنا هنا: https://github.com/aspnet/libuv-build/

ويشير إلى كود مصدر libuv عبر وحدة Git الفرعية: https://github.com/aspnet/libuv-build/tree/dev/submodules

وأخيرًا ، يمتلك فريق ASP.NET مستودعًا لأخذ ثنائيات libuv وتعبئتها في حزمة NuGet: https://github.com/aspnet/libuv-package

ccmoozzyk الذي يعرف أكثر عن بناء libuv.

ماذا قال إيلون .
تم إنشاء الحزم لأنظمة تشغيل / بنى مختلفة (حاليًا Windows Win32 / x64 / arm و Linux (64 بت) و macOS) من هذا الريبو https://github.com/aspnet/libuv-build/ (الذي يسحب كود libuv باعتباره subodule) ودفعها إلى myget feed كحزم Microsoft.AspNetCore.Internal.libuv- * OS الخاصة بنظام التشغيل. libuv-package repo مسؤول عن سحب حزم الإنشاء وإنشاء حزمة über libuv التي تحتوي على وحدات بت لجميع البنى المدعومة.

qmfrederik لقد أرفقت كرة تار .NET Core Runtime لـ Ubuntu 14.04 ARM. عندما أكون جاهزًا لـ Ubuntu 16.04 ، سأشارك الملف هنا. (تم التحديث في 12/26: لقد أرفقت كرة تار .NET Core Runtime لـ Ubuntu 16.04 ARM.)
dotnet-ubuntu-arm.1.2.0-beta-001206-00.tar.gz (Ubuntu 14.04 ARM)
dotnet-ubuntu-arm.1.2.0-beta-001206-00.tar.gz (Ubuntu 16.04 ARM)

@ gkhanna79

هذا هو العمل الذي أتبعه لإنجازه كجزء من دعم بناء خط أنابيب E2E عبر مستودعات NET Core الثلاثة (CoreCLR و CoreFX و Core-Setup).

شكرا لدعمكم!

Eilonmoozzykqmfrederik شكرا لك على التعليقات. في الواقع ، نحن لا نحتاج إلى libuv.so في الوقت الحاضر. ومع ذلك ، يبدو أن libuv for Linux arm مطلوب لإصدار .NET Core Runtime لـ Ubuntu ARM. هل يجب علي إضافة حزمة libuv لـ Linux arm؟ ما رأيك؟

jyoungyun - الشيء الوحيد الذي يتطلب حاليًا libuv هو Asp.NET Core Http Server - Kestrel . إذا كنت لا تستخدم Asp.NET Core ، يمكنك الحصول عليه بدون libuv.
نستخدم حاليًا نوعًا من طريقة البيرة لبناء libuv لمنصات مختلفة (أحد الأسباب هو أن البرامج النصية الخاصة بهم لا تدعم Windows ARM) ولكن في النهاية سيكون من الجيد فقط إنشاء libuv باستخدام البرامج النصية من الريبو الخاص بهم مما يجعل تمكين الأنظمة الأساسية الجديدة أسهل.

لعلمك. لقد ركضت فوق dotnet tarball في Raspberry Pi3 وهو ubuntu.16.04-arm.
على الأقل ، يعمل بشكل جيد مع HelloWorld.exe والتطبيقات البسيطة الأخرى. :) شكرا jyoungyun !

هل لديك أي أتمتة حول الاختبارات على المخلفات الخطرة الحقيقية؟ تفكيري الحالي هو تقييم القيام بذلك لصالح المحاكي في المستقبل المنظور.

@ gkhanna79 لسوء الحظ ، ليس لدينا اختبارات CoreCLR / CoreFX آلية على HW ويستغرق الأمر أيضًا عدة ساعات لإجراء اختبارات وحدة CoreCLR كاملة على جهاز ARM ، على سبيل المثال Rpi2 أو Rpi3.
نحن مهتمون أيضًا بالاختبار أدناه ولكني أخشى أن اختبارات CoreCLR / CoreFX الكاملة قد لا تكون مجدية لـ ARM HW بسبب انتهاء المهلة ، على سبيل المثال اختبارات CoreFX تعمل لفترة أطول بكثير من CoreCLR. لذلك أعتقد أنه قد يتعين علينا اختيار الاختبارات حتى عندما تكون البنية التحتية متاحة.

يبدو أنه تم دمج dotnet / core-setup # 712 ، لذا يمكننا التحقق من ذلك!

قم بتحديث البرنامج النصي للبناء لتمكين البناء المشترك (سيتم نشر العلاقات العامة قريبًا.)

jyoungyun أعتقد أنك أكملت هذا من أجل Core-Setup ، أليس كذلك؟ إذا كان الأمر كذلك ، هل يمكنك إضافة تفاصيل العلاقات العامة أعلاه وإلغاء تحديد ذلك :)؟

قم بتحديث البرنامج النصي للبناء لتمكين التنزيل والتعبئة لنظام التشغيل Linux / ARM.

hqueue ما الذي يدور حوله هذا العنصر (مدرج ضمن قسم الإعداد الأساسي)؟

هل يجب علي إضافة حزمة libuv لـ Linux arm؟ ما رأيك؟

jyoungyun أعتقد أنه سيكون فكرة جيدة أن تكون التغييرات جاهزة لبناء lib-uv لـ arm32 (كما تم تتبعه من خلال https://github.com/aspnet/libuv-build/issues/19).

@ gkhanna79jyoungyun - هل Linux / arm RID كاف رغم ذلك؟ ماذا عن التعويم الصعب مقابل الطفو الناعم؟ لا ينقل نظام Linux-arm RID هذه المعلومات ....

يبدو أن الاتفاقية في مستودعات dotnet هي أن arm = armhf ، و softp must
صراحة. ربما يمكن إضافة تخليص ناعم الذراع إذا
من الضروري

في 27 ديسمبر 2016 ، الساعة 7:01 مساءً ، كتب "Pawel Kadluczka" [email protected] :

@ gkhanna79 https://github.com/gkhanna79jyoungyun
https://github.com/jyoungyun - هل Linux / arm RID كافٍ رغم ذلك؟ كيف
حول التعويم الصعب مقابل الطفو الناعم؟ لا ينقل نظام لينكس ذراع RID هذا
معلومة....

-
أنت تتلقى هذا لأنك علقت.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/dotnet/core-setup/issues/725#issuecomment-269400424 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AAL9OFobHMUWCNgwxEvC8nLJMdvM1PJtks5rMabfgaJpZM4LD3ey
.

أعتقد أنك أكملت هذا لـ Core-Setup ، أليس كذلك؟ إذا كان الأمر كذلك ، هل يمكنك إضافة تفاصيل العلاقات العامة أعلاه وإلغاء تحديد ذلك :)؟
عن ماذا يدور هذا العنصر (تم إدراجه ضمن قسم الإعداد الأساسي)؟

@ gkhanna79 في البداية ، اعتقدنا أنها مهام أخرى وكنت أخطط لإعداد علاقات عامة منفصلة لكل مهمة. ولكن كما لاحظت بالفعل ، فقد مكنتهم PR dotnet / core-setup # 712 من تمكينهم تمامًا. سوف أفحصهم. شكرا لإعلامنا :)

هل Linux / arm RID كافٍ رغم ذلك؟ ماذا عن التعويم الصعب مقابل الطفو الناعم؟ لا ينقل نظام Linux-arm RID هذه المعلومات ....

moozzyk @ stevedesmond-ca @ gkhanna79jyoungyun لدي أيضًا نفس السؤال منذ بدء هذه المهمة وعلى سبيل المثال لا يوجد تمييز في ألعاب Ubuntun بين العوامات ABI المختلفة (مثل hardfp ، soft ، softfp). قد يؤثر هذا على جميع اتفاقيات إعادة الشراء النقطية الأخرى بما في ذلك CoreCLR و CoreFX.

يبدو أن الاتفاقية في مستودعات dotnet هي أن arm = armhf ، و softp must
صراحة. ربما يمكن إضافة تخليص ناعم الذراع إذا
من الضروري

@ stevedesmond- camoozzyk @ gkhanna79hqueue لا يحتوي Linux RID على معلومات ABI العائمة ، لكننا نستخدمها بالفعل مع RID ومعلومات ABI العائمة كمؤشر بناء. كما هو مذكور أعلاه @ stevedesmond-ca ، إذا لزم الأمر ، يمكننا إضافة ذراع softfp مثل CoreCLR و CoreFX repos. أرغب في الاحتفاظ بالهيكل الحالي حول معلومات RID و ABI العائمة في core-setup و libuv-build. وسنقوم بإضافة arm-softfp إلى الإعداد الأساسي قريبًا لدعم نظام التشغيل Tizen OS. Tizen يدعم فقط ذراع softfp.

@ gkhanna79 تم دمج كل الأعمال الخاصة ببناء الإعداد الأساسي لـ Ubuntu ARM بالفعل عبر dotnet / core-setup # 712. وسوف أنشر العلاقات العامة قريبًا لتعطيل الهدف GenerateDebs بخصوص dotnet / core-setup # 849.

@ gkhanna79 أفكر أيضًا في إضافة Tizen إلى Linux ARM32 وسيتم تشغيله من أسفل إلى أعلى ، أي بدءًا من CoreCLR و CoreFX كما فعلنا مع ubuntu 14.04 و 16.04. أعتقد أنه يمكننا اتباع خطوات مماثلة. ما رأيك في ذلك؟ يمكنني إنشاء CoreCLR لـ Tizen الآن ويمكنني إضافة ملفات rootfs لـ Tizen متى تمت الموافقة عليها.

hqueuejyoungyun يجب أن أعترف أنني لست على دراية كبيرة بالفرق بين fp الناعم والصلب. هل يمكنك توضيحها قبل أن نسير في طريق تحديد ما إذا كانت تتطلب RIDs جديدة أم لا؟

إضافة Tizen إلى Linux ARM32 وسيبدأ من الأسفل إلى الأعلى

hqueue بشكل عام ، يبدو المفهوم جيدًا بالنسبة لي. ومع ذلك ، قبل المضي قدمًا في ذلك ، أود أن أفهم الفرق بين Tizen (المصمم لنظام Linux Arm32) ونظام Linux Arm32 .NET Core العادي - هل يمكنك مشاركة المزيد من التفاصيل حوله؟

هل يمكنك توضيحها قبل أن نسير في طريق تحديد ما إذا كانت تتطلب RIDs جديدة أم لا؟

@ gkhanna79 يعرّف GNU ثلاثة ABI عائمة لـ ARM ، مثل soft ، softfp و hard . (انظر الجزء -mfloat-abi=name على https://gcc.gnu.org/onlinedocs/gcc/ARM-Options.html) الاختلاف الرئيسي بين softfp و hard هو كما يلي .

• GNU hard ABI: استخدام إرشادات الفاصلة العائمة + استخدام اصطلاحات الاستدعاء الخاصة بـ FPU (مثل استخدام سجلات FP لمعلمات الفاصلة العائمة وقيم الإرجاع)
• GNU softfp ABI: استخدام إرشادات الفاصلة العائمة + استخدام اصطلاحات استدعاء soft-float (على سبيل المثال ، استخدام سجلات مكدس أو عدد صحيح لمعلمات الفاصلة العائمة وقيم الإرجاع)

لذلك لا يمكنك استخدام جهازي ABI معًا ، لأن اصطلاحات الاستدعاء مختلفة.

في dotnet ، نستخدم hard و softfp لـ ARM. (لا يوجد soft ABI.)

• hard ABI: إصدار افتراضي لـ ARM32 على سبيل المثال ./build.sh arm
• softfp ABI: يمكننا البناء باستخدام ./build.sh arm-softfp

وجميع الثنائيات في rootfs arm لها hard ABI والثنائيات في arm-softfp rootfs لها softfp ABI.

أرغب في فهم الفرق بين Tizen (المصمم لنظام Linux Arm32) ونظام Linux Arm32 .NET Core العادي - هل يمكنك مشاركة المزيد من التفاصيل حوله؟

@ gkhanna79 بشكل أساسي يمكنك اعتبار Tizen توزيعة أخرى Linux/arm-softfp .
الاختلاف الرئيسي هو إصدار المكتبات / النواة وتكوين الحزم في كل توزيع ، على سبيل المثال إصدار libicu مختلف.
يشبه الاختلاف الفرق بين ubuntu.14.04 و ubuntu.16.04 في Linux Arm32 .NET Core.

بالمختصر،

• لدينا الآن ubuntu.14.04 rootfs مقابل Linux/arm-softfp ويمكننا إنشاء ubuntu.14.04 باستخدام ARM softfp ABI.
• إذا أضفنا Tizen rootfs ، فسنحصل على اثنين من rootfs مقابل Linux/arm-softfp ، أي ubuntu.14.04 و Tizen ، ونحن قادرون على البناء لـ ubuntu.14.04 و Tizen باستخدام ARM softfp ABI.

لعلمك. في CoreCLR ، لدينا إجمالي 5 rootfs مقابل Linux/arm (hardfp) ، أي jessie ، vivid ، trusty ، sily and xenial.

أحاول أن أشرح باختصار لتجنب الالتباس. إذا كان لديك أي سؤال ، فيرجى إبلاغي بذلك :)

وجميع الثنائيات في جذور الذراع لها ABI صلبة والثنائيات في جذر softfp للذراع لها softfp ABI

شكرا على الشرح @ hqueue. أوافق على أننا نقوم بتمكين soft-fp بكسل إذا / بمجرد ظهور الحاجة.

شكرًا على الشرح المختصر لـ Tizenhqueue. بصرف النظر عن الاختلافات بين ثنائيات النظام الأساسي / إصدار kernel ، هل يحمل Tizen نفس مجموعة الثنائيات مثل .NET Core عادةً؟ أي عند إنشاء تطبيق Tizen ، هل تستهدف أساسًا .NET Core (وبالتالي ، لديك FX مشترك قائم على Microsoft.NETCore.App) أم لديك (أو تخطط لامتلاك) آلية استهداف مختلفة (مثل Samsung. حزمة Tizen) التي يمكن أن تحمل مجموعة مختلفة من الثنائيات؟

أيضًا ، كيف يتم تنشيط تطبيقات Tizen؟ هل يتم تنشيطها بنفس طريقة تنشيط تطبيقات .NET Core (باستخدام dotnet.exe) أم بطريقة أخرى؟

في الأساس ، hqueue ، أحاول أن أفهم ما إذا كانت Tizen هي مجرد توزيعة مكافئة أخرى لـ .NET Core أو تجربة استهداف / AppModel جديدة تمامًا.

@ gkhanna79 أعتقد أن هناك عدة أسئلة هنا.

هل يحمل Tizen نفس مجموعة الثنائيات مثل .NET Core عادةً؟

بالنسبة إلى CoreCLR و CoreFX ، صحيح. سنستخدم نفس مجموعة الثنائيات بالضبط في Linux / arm-softfp ، و AFAIK لا يوجد فرق بين Linux / ARM و Linux / arm-softfp الآن.

تستخدم Tizen نفسها نظام تعبئة RPM للمنصة. يتم بالفعل إنشاء CoreCLR و CoreFX for Tizen باستخدام نظام إنشاء Tizen (https://build.tizen.org) في مجتمع Tizen (https://www.tizen.org).
CoreCLR for Tizen: https://build.tizen.org/package/show؟package=coreclr&project=Tizen٪3AMobile
CoreFX for Tizen: https://build.tizen.org/package/show؟package=corefx&project=Tizen٪3AMobile

أي عند إنشاء تطبيق Tizen ، هل تستهدف أساسًا .NET Core (وبالتالي ، لديك FX مشترك قائم على Microsoft.NETCore.App) أم لديك (أو تخطط لامتلاك) آلية استهداف مختلفة (مثل Samsung. حزمة Tizen) التي يمكن أن تحمل مجموعة مختلفة من الثنائيات؟
أيضًا ، كيف يتم تنشيط تطبيقات Tizen؟ هل يتم تنشيطها بنفس طريقة تنشيط تطبيقات .NET Core (باستخدام dotnet.exe) أم بطريقة أخرى؟

هناك نموذج تطبيق serveral في Tizen وسيكون .NET Core واحدًا منهم. أعتقد أن هذا يمكن تفسيره من خلال lemmaa وidkiller.
lemmaaidkiller يرجى النظر في هذه الاستفسارات.

أحاول أن أفهم ما إذا كانت Tizen هي مجرد توزيعة مكافئة أخرى لـ .NET Core أو تجربة استهداف / AppModel جديدة تمامًا.

@ gkhanna79 لا أعتقد أنه يوفر تجربة جديدة تمامًا. نظرًا لأن Tizen سيعمل كتوزيعة أخرى لنظام Linux ، على الأقل أعتقد أنه يمكنك اعتباره مكافئًا لتوزيعة أخرى لـ .NET Core.
lemmaaidkiller ما رأيك في ذلك؟

أعتقد أنه يمكننا مواصلة المناقشة العام المقبل لمزيد من التفاصيل :)

@ gkhanna79hqueue @ hseok-oh ما رأيك في تسمية arm-softfp كـ armsf لـ nupkgs؟ أعتقد أنه لا يبدو جميلًا أن يكون لديك - بين اسم buildarch. من فضلك أعطني فكرة جيدة. :)

jyoungyun ماذا عن استخدام armel لأذرع softfp؟ يبدو أن armel يُستخدم لثنائيات ARM softfp في Ubuntu وسيكون أمرًا رائعًا إذا تمكنا من اتباع الاصطلاحات في مجتمع Linux.

راجع https://wiki.ubuntu.com/ToolChain

armel: تعويم ناعم ABI / تعويم صلب ABI ، افتراضيًا إلى arm-linux-gnueabi.
armhf: تعويم ثابت ABI / تعويم ناعم ABI ، افتراضيًا إلى arm-linux-gnueabihf.

@ gkhanna79 إذا كان target يعني "مكتبة إطار العمل الأساسي" ، فإن Tizen الحالية تستخدم Microsoft.NETCore.App كإطار عمل أساسي لتطوير تطبيقات المستخدم.
لكننا نستخدمه فقط "كإطار عمل أساسي" ، لا يتم تنفيذ Tizen Apps مثل تطبيقات dotnet الأخرى.
لم تستخدم Tizen dotnet.exe أو أداة أخرى مثل corerun ، coreconsole.
Tizen لديه قاذفة أصلية ويستخدم داخليًا واجهة libcoreclr.so مباشرة.
في هذا النموذج ، يجب أن تكون الملفات الثنائية وملفات dll في coreclr و Microsoft.NETCore.App مثبتة مسبقًا على الجهاز ويجب تشغيل التطبيق مثل Framework-dependent deployments . تحتوي حزمة التطبيق الفعلية فقط على dll أو exe من تبعية التطبيق أو التطبيق.
لكن في هذه الأيام ، نعد نموذجًا آخر مثل Self-contained deployments . يجب استخدامه في الجهاز الذي لا يحتوي على وقت تشغيل.
بالنسبة إلى التغليف ، لا يتم حزم تطبيقات Tizen مع nupkg. (يستخدم tpk )
هناك بعض واجهات برمجة التطبيقات لتطبيقات Tizen ( https://git.tizen.org/cgit/?q=csapi )
البناء الداخلي لواجهات برمجة التطبيقات هذه في GBS وإنشاء تطبيق للمستخدم في VisualStudio يستخدم nupkg ولكن التطبيق غير معبأ في nupkg.

jyoungyun أنا أتفق مع hqueue على متابعة الاتفاقية. نظرًا لأن لدينا بالفعل "arm" RID (على https://github.com/dotnet/corefx/blob/master/pkg/Microsoft.NETCore.Platforms/runtime.json) ، فسنستخدمه لـ hardfp (والمرادف ل armhf أعلاه). للحصول على دعم softfp ، يبدو Armel جيدًا بالنسبة لي وشيء يجب أن نضيفه على https://github.com/dotnet/corefx/blob/master/pkg/Microsoft.NETCore.Platforms/runtime.json.

CCjanvorli

فمن المنطقي بالنسبة لي.

hqueue @ gkhanna79janvorli أتفق أيضًا مع رأي hqueue ! يبدو جيدا للغاية بالنسبة لي. سأقوم بنشر العلاقات العامة لدعم بناء Armel على الإعداد الأساسي قريبًا.

MustafaHosny اللهم امين قمنا بإعداد العلاقات العامة لـ armel في CoreCLR و CoreFX وقمنا بتحديث جدول أعمال هذه المشكلة المرتبط بـ armel . نحن نعمل على Core-Setup أيضًا. لقد قمت أيضًا بتحديث موضوع Tizen في جزء arm-softfp (armel). يرجى أيضًا إلقاء نظرة :)

لدينا الآن ubuntu.14.04 rootfs لنظام Linux / arm-softfp ويمكننا إنشاء ubuntu.14.04 باستخدام ARM softfp ABI.

@ gkhanna79 لقد أخطأت في الإجابات السابقة. بالنسبة لبرنامج ARM softfp ، نستخدم debian 8 (jessie) rootfs وليس ubuntu14.04 . لذلك سيكون التخلّص من debian.8-armel إذا استخدمنا armel لـ softfp ARM.

hqueue لقد قمت بتنظيف / إعادة ترتيب بنود العمل لـ armel و Tizen.

@ gkhanna79 https://dotnet.myget.org/feed/aspnetcore-ci-dev/package/nuget/Libuv/1.10.0-preview1-22036 يحتوي على إصدارات arm من Libuv لنظام Linux. اسمحوا لي أن أعرف بمجرد نسخ الحزمة ويمكنني تحديث https://github.com/dotnet/core-setup/blob/master/pkg/projects/Microsoft.NETCore.App/project.json#L43

moozzyk لقد قمت بتحميله إلى myget ويجب أن يكون مرئيًا بمجرد أن تجعله أداة myget مرئية في :)

@ gkhanna79 - محدث. أعتقد أنه يمكنك تحديد "Build LibUV for Arm32 (إصدار aspnet / libuv-build # 19)." التحقق.

تضمين التغريدة

@ gkhanna79 هل يجب أن نقدم sdk لتحرير arm و armel رسميًا؟ و .. هل يجب أن تدعم sdk tarball لحل NETCoreApp1.1 (سيكون NETCoreApp2.0 ) للإصدار الرسمي؟ هل يمكنك إخبارنا بما نحتاجه للاستعداد لإصدار رسمي؟ في الوقت الحالي ، فإن sdk tarball الذي صنعته من مشروع cli لا يعالج NETCoreApp1.1 بسبب خطأ Unable to resolve dependency 'Microsoft.CodeAnalysis.CSharp' . لذلك أتساءل عما إذا كان عليّ حل هذه المشكلة للإصدار الرسمي وإذا كان عليّ إصلاح roslyn لإصلاحها.

من فضلك jyoungyun ، هل يمكنك تحميل مشروع HellowWorld الخاص بك والصناديق؟ لدي:
Raspberry Pi3 + ubuntu.16.04-arm + dotnet-ubuntu-arm.1.2.0-beta-001206-00.tar.gz.

هل يمكن أن تخبرني من فضلك كيف أجمع مشروع netcore لتشغيله على Raspberry؟ أنا أستخدم النوافذ.

شكرا

@ scrambler86 مرحبًا ، لقد أرفقت sdk tarball لـ ubuntu.14.04-arm. حتى هذا الملف مخصص لـ ubuntu.14.04-arm ولكني أعتقد أنه لا بأس من تشغيله على ubuntu.16.04-arm. بعد تثبيت sdk tarball ، يمكنك استخدام الأمر dotnet new لإنشاء مشروع HelloWorld. عادةً ما أقوم ببناء الإعداد الأساسي ومشروع cli بالترتيب التالي.

1. بناء CoreCLR لـ ubuntu.14.04-arm
2. قم ببناء CoreFX لـ ubuntu.14.04-arm
3. انسخ نتائج nupkgs من CoreCLR و CoreFX إلى دليل محدد وأضف السطر أدناه إلى ملف NuGet.Config في الإعداد الأساسي.

<add key="Local" value="The speicific directory path" />

1. بناء الإعداد الأساسي باستخدام الأمر ./build.sh --skiptests --env-vars DISABLE_CROSSGEN=1,TARGETPLATFORM=arm,TARGETRID=ubuntu.14.04-arm,CROSS=1,ROOTFS_DIR=/home/jyoung/git/dotnet/rootfs/arm .
2. انسخ نتائج nupkgs من الإعداد الأساسي إلى دليل محدد وأضف السطر العلوي إلى NuGet.Config في cli.
3. أنشئ cli باستخدام الأمر ./build.sh --env-vars DOTNET_RUNTIME_ID=ubuntu.14.04-arm -c Release /p:CLIBUILD_SKIP_TESTS=true /p:DISABLE_CROSSGEN=1 .
   ولكن لاستخدام الخيار --env-vars ، يحتاج cli إلى https://github.com/dotnet/cli/pull/5290 PR.

dotnet-sdk-ubuntu.14.04-arm.1.0.0-preview5-004431.tar.gz

jyoungyun شكرًا لك على مساعدتك ، إنه محل تقدير كبير!
@ scrambler86 لقد وجدت للتو هذا المنشور أيضًا والذي قد يكون مفيدًا https://github.com/dotnet/core/blob/master/samples/RaspberryPiInstructions.md

لقد قمت بتحديث كرات القطران لوقت التشغيل المشترك لـ ubuntu.14.04 arm و ubuntu.16.04 arm. تحتوي كرات القطران هذه على libuv.so و CodeAnalysis dlls التي كانت مفقودة من كرات القطران الأخيرة.

وقمت أيضًا بتحميل تار sdk لـ rpi3.
يمكنك استخدامه بالترتيب التالي.

1. قم باستخراج وقت التشغيل المشترك المطابق و sdk tar.gz إلى نفس المجلد على Pi الخاص بك وانتقل إلى هذا المجلد في الجهاز .
   dotnet-ubuntu.14.04-arm.1.2.0-beta-001291-00.tar.gz (وقت التشغيل المشترك)
   dotnet-sdk-ubuntu.14.04-arm.1.0.0-preview5-004431.tar.gz (sdk)
   dotnet-ubuntu.16.04-arm.1.2.0-beta-001291-00.tar.gz (وقت التشغيل المشترك)
   dotnet-sdk-ubuntu.16.04-arm.1.0.0-preview5-004431.tar.gz (sdk)

mkdir dotnet
tar xvzf dotnet-ubuntu.16.04-arm.1.2.0-beta-001291-00.tar.gz -C ./dotnet
tar xvzf dotnet-sdk-ubuntu.16.04-arm.1.0.0-preview5-004431.tar.gz -C ./dotnet

1. أنشئ ارتباطًا رمزيًا من dotnet إلى /usr/bin/dotnet .
   ln -sf /usr/bin/dotnet /yourpath/dotnet/dotnet
2. قم بإنشاء مجلد باسم helloworld وانتقل إليه.
3. قم بتشغيل dotnet new ثم dotnet restore ثم dotnet publish لنشر تطبيق helloworld الخاص بك.
   ولكن ، في حالتي ، لم أستطع النجاح في حل NETCoreApp1.1 حتى الآن على الرغم من أن لدي ملفات nupkg ذات الصلة.

لقد دفعت للتو بعض التعليمات البسيطة إلى dotnet / core master. يشيرون إلى بعض كرات القطران القديمة. سوف أقوم بتعديله للإشارة إلى هؤلاء. نتطلع إلى متى يمكن أن تكون هذه جزءًا من البناء اليومي. :)

https://github.com/dotnet/core/blob/master/samples/RaspberryPiInstructions.md

@ scrambler86 ، في الأسبوعين المقبلين ، يجب أن نكون قادرين على نشر جميع الحزم من أجل إنشاء تطبيق مستقل على Windows يستهدف arm32 linux. هذا ما نحتاجه للحصول على تجربة المطور على نظام Windows الذي يستهدف Raspberry Pi بشكل كامل. في الوقت الحالي ، إذا كان التطبيق الذي تكتبه لا يحمل وقت التشغيل معه ويمكن تشغيله فقط في وقت التشغيل المشترك ، فيجب أن تكون قادرًا على النشر على Windows ونسخ الإخراج المنشور إلى Pi الخاص بك. جربها وأخبرنا بذلك.

jyoungyun ، هل لديك nuget.config يشير إلى مجلد محلي يحتوي على حزمك؟ بدون ذلك ، لا أعتقد أنه سيعرف كيفية العثور عليها.

jyoungyun سيتم تحديث جميع الفروع الرئيسية لحل .NETCoreApp 2.0. ومع ذلك ، قبل حدوث ذلك ، نحتاج إلى نشر حزم nuget التي أعمل عليها منذ فشل build-rootfs.sh في البنية التحتية الرسمية للبناء.

إذن كل هذا العمل الجميل يهدف إلى 2.0 ، أم أنه إصدار 1.2؟

1.2 قيد إعادة تسمية 2.0

ومع ذلك ، قبل حدوث ذلك ، نحتاج إلى نشر حزم nuget التي أعمل عليها منذ فشل build-rootfs.sh في البنية التحتية الرسمية للبناء.

@ gkhanna79 هل لديك مشكلة مع buiild-rootfs.sh for arm and armel ، مثل ./build-rootfs.sh arm و ./build-rootfs.sh armel ؟ ما نوع المشكلة التي تعاني؟ أعتقد أنه يمكننا أيضًا النظر في porblem إذا أمكن ذلك.

كان الأمر يتعلق بالبناء في Docker وهي الطريقة التي نبني بها العديد من أرجل Linux الخاصة بنا من بنائنا.

Petermarcu نعم ، لقد قمت بتحديث ملف NuGet.Config للإشارة إلى مجلد محلي يحتوي على nupkgs الخاص بنا. لكنها ما زالت تفشل في حل NETCoreApp1.1. رسالة الخطأ كما هو موضح أدناه.

Retrying 'FindPackagesByIdAsync' for source 'https://api.nuget.org/v3-flatcontainer/system.globalization/index.json'.
  A task was canceled.

أشك إذا كانت قضية شبكة الشركة. هل رأيت مثل هذا الخطأ من قبل؟

أنا لم أفعل. ericstj أي أفكار؟

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

حسنًا ، 2.0 هو كذلك. شكرا @ stevedesmond-ca.
لذا فإن جهد الإعداد الأساسي للذراع سيظهر لأول مرة في الإصدار 2.0؟

كان الأمر يتعلق بالبناء في Docker وهي الطريقة التي نبني بها العديد من أرجل Linux الخاصة بنا من بنائنا.

تضمين التغريدة بين الجذور الجذرية للذراع ، فإن rootfs لـ armel ( Tizen ) (تم إنشاؤها من build-rootfs.sh armel tizen ) لديها بنية أبسط من الجذور الأخرى ( ubuntu و debian ) وتتطلب أقل مجهود. على سبيل المثال ، تحتوي ملفات rootf لـ armel ( Tizen ) فقط على المكونات المطلوبة للبناء (حوالي 100 ميجابايت) ، ولكن تحتوي جذور الجذر الأخرى ، مثل arm ( Ubuntu ) و armel ( Debian ) ، لديك جميع مكونات Linux لتوزيعة Linux الافتراضية (حوالي 700 ميجابايت) وتتطلب عملية debootstrap مع sudo previledge خلال build-rootfs.sh . لذلك يتطلب المزيد من الموارد بما في ذلك النطاق الترددي للشبكة والتخزين والحساب.
نواجه أيضًا فشلًا في وقت ما في مربع Linux x64 المضيف عند إنشاء ملفات rootf لـ ubuntu-arm و debian-armel لأسباب مختلفة بما في ذلك مشكلة الشبكة وما إلى ذلك ، لذلك إذا كنت تواجه مشكلة في إنشاء جذر ARM في بيئة عامل الإرساء ، فإنني أقترح المحاولة بشكل أبسط جذور تايزن.

hqueue تسببت حقيقة أن صور Docker عبارة عن حاوية وليست بيئة افتراضية في حدوث مشكلات - وليس لها علاقة بإنشاء ملفات rootf.

كانت المشكلة المحددة هي أنني تمكنت من إنشاء LinuxArm32 في صورة Docker على جهاز التطوير الخاص بي ولكن لم أتمكن من القيام بذلك في بنائنا الرسمي. بعد التحقق من الخيارات المختلفة ، اتبعت نهجًا مختلفًا لمقارنة الاختلافات بين حالة النجاح والفشل. تكمن المشكلة في أنه ، حتى عند محاولته داخل حاوية Docker ، يتوقع البناء المتقاطع (في استدعاء المرحلة الثانية الذي يبدأ qemu-debootstrap) أن الجهاز المضيف به تبعيات بناء متقاطعة مثبتة أيضًا. نظرًا لأنها لم تكن موجودة في صورة نظام التشغيل المضيف في بنائنا الرسمي ، ولم تكن موجودة إلا في حاوية Docker ، فإن البناء المتقاطع داخل حاوية Docker سيفشل.

لقد قمت بإيقاف تشغيل إحدى آلات البناء الرسمية الخاصة بنا أمس ، وتم تثبيت الحزم المفقودة وحصلت أخيرًا على بنية Linux Arm32 نظيفة في صورة Docker! :) سوف أقوم بتحديث أجهزتنا الرسمية وسأبدأ قريبًا.

مع ما سبق ذكره ، نحتاج إلى إنتاج .NET Core لكل من armhf و armel. وبالتالي ، سيكون بناء debian.8-armel أو Tizen armel مادة مضافة وليست بديلاً عن بناء armhf.

@ gkhanna79 سعيد لسماع التقدم وشكرا على كل ما تبذلونه من جهود :)

تحديث الخيط الأساسي - تنشر CoreCLR pipeline build حزم Arm32 (armhf) لـ Ubuntu 14.04 و Ubuntu 16.04 على myget! فيما يلي المجموعة الأولى من الحزم التي تم نشرها اليوم من الريبو:

https://dotnet.myget.org/feed/dotnet-core/package/nuget/runtime.ubuntu.14.04-arm.Microsoft.NETCore.Runtime.CoreCLR

https://dotnet.myget.org/feed/dotnet-core/package/nuget/runtime.ubuntu.16.04-arm.Microsoft.NETCore.Runtime.CoreCLR

@ gkhanna79 بادئ ذي بدء ، شكراً جزيلاً لنشر الحزم لـ CoreCLR :)

لقد اختبرنا الحزم أعلاه ، ولكن لسوء الحظ ، أعتقد أنه يحتوي على خطأ بسبب clang والذي يتم استخدامه عند بناء CoreCLR.

لا يمكن لـ llvm-3.8 الحالي والإصدارات الأقل إنشاء CoreCLR و CoreFX بشكل صحيح باستخدام تحسين -O3 لـ ARM ، نظرًا لوجود خطأ متعلق بـ TLS. يمكنك العثور على التفاصيل على https://github.com/dotnet/coreclr/blob/master/Documentation/building/linux-instructions.md#how -to-enable - o3-optimization-level-for-armlinux
(هناك الكثير من المشكلات المتعلقة بهذا. إحداها https://github.com/dotnet/coreclr/issues/6530)

لذلك أعتقد أنه يتعين علينا التفكير في ترقية إصدار llvm لإصدار ARM وسنناقش أيضًا هذه المشكلة مع مشكلة dotnet / core-setup # 790 (arm32 CI). دعنا ننتقل إلى dotnet / core-setup # 790 وسأواصل المناقشة هناك.

راجع للشغل أبسط الحلول هي استخدام "-O1" بدلاً من "-O3" عند بناء CoreCLR مع الهياكل التحتية الحالية.

جيد جدًا @ hqueue - سأستمر في المناقشة معك على dotnet / core-setup # 790.

تنبيه ، في حالة رغبة أي شخص آخر ، لديّ إصدارات آلية من .NET Core Runtime لـ ubuntu.16.04-arm تعمل الآن ، عبر مجموعة من البرامج النصية bash.

https://github.com/stevedesmond-ca/dotnet-arm/releases/

أخطط لنشر النشرات الليلية (بما في ذلك SDK خلال الأسبوع المقبل) هناك حتى يمكن إعداد تصميمات CI الرسمية.

ممتاز @ stevedesmond-ca! أنا أعمل على دعم CoreFX للبنيات الرسمية الآن.

راجع للشغل ، هل بنياتك لـ Ubuntu 14.04 أو 16.04؟ وأعتبر أنك تستهلك الحزم التي ننشرها لـ CoreCLR بالفعل ، أليس كذلك؟

16.04 الآن فقط. أنا أقوم ببناء CoreCLR و CoreFX من البداية ، ثم أقوم بتغذية القطع الأثرية من تلك في الإعداد الأساسي ، مشابه جدًا لكيفية وصف jyoungyun هنا .

بمجرد إنشاء CoreCLR في myget مع -O1 (حاليًا أحصل على خطأ -O3 TLS من ما تم سحبه) ، يجب أن يكون استخدام الإصدارات الرسمية أسهل. أعتقد أن هناك قيمة في أن تكون قادرًا على القيام بكل شيء في وضع عدم الاتصال ، لفصل عملية الإنشاء عن عملية نشر CI الحالية ، ولكن هذا مجرد تفضيلي الشخصي.

@ stevedesmond-ca حاولت تشغيل حاوية عامل إرساء مدمجة على RPi3 باستخدام ملف الرصيف التالي:

FROM armv7/armhf-ubuntu:16.04

ENV VERSION 2.0.0-beta-001455-00

RUN apt-get update -q -y && \
apt-get upgrade -q -y && \
apt-get install -q -y wget

RUN wget https://github.com/stevedesmond-ca/dotnet-arm/releases/download/$VERSION/dotnet-ubuntu-arm.$VERSION.tar.gz && \
mkdir -p /usr/share/dotnet && \
tar -xf dotnet-ubuntu-arm.$VERSION.tar.gz -C /usr/share/dotnet/ && \
ln -sf /usr/share/dotnet/dotnet /usr/bin/dotnet

RUN mkdir dotnet
COPY dotnet-arm/hello-world/hello-world.csproj dotnet/hello-world.csproj
COPY dotnet-arm/hello-world/hello-world.deps.json dotnet/hello-world.deps.json
COPY dotnet-arm/hello-world/hello-world.dll dotnet/hello-world.dll
COPY dotnet-arm/hello-world/hello-world.pdb dotnet/hello-world.pdb
COPY dotnet-arm/hello-world/hello-world.runtimeconfig.json dotnet/hello-world.runtimeconfig.json
COPY dotnet-arm/hello-world/Program.cs dotnet/Program.cs

أبدأ بعد ذلك الحاوية بـ docker run -it core /bin/bash ونفذت في مجلد dotnet dotnet hello-world.dll ، ولكن بعد ذلك أتلقى خطأ:

Failed to load /usr/share/dotnet/shared/Microsoft.NETCore.App/2.0.0-beta-001455-00/libcoreclr.so, error: libunwind.so.8: cannot open shared object file: No such file or directory
Failed to bind to CoreCLR at '/usr/share/dotnet/shared/Microsoft.NETCore.App/2.0.0-beta-001455-00/libcoreclr.so'

أي تلميح عن أي خطأ غبي أقوم به؟

bjoernbusch تحقق من https://github.com/dotnet/core/blob/master/samples/RaspberryPiInstructions.md - تحديدًا جزء "الحزم المسبقة" - الاحتمالات غير موجودة في الصورة الأساسية

نعم! نخيل الوجه الذي كان عليه ، الآن يعمل! شكرا!

@ stevedesmond-ca شكرًا لك على مشاركة tarball الخاص بك :) إنه يعمل جيدًا على Raspberry PI3 أيضًا. الآن أحاول بناء الإعداد الأساسي باستخدام عامل الإرساء. هل يستخدم نظام CI الخاص بك عامل إرساء للإفراج ، أليس كذلك؟ ولكن عندما حاولت البناء باستخدام عامل الإرساء ، واجهت مشكلة صغيرة تتمثل في إزالة جميع الحجج التي تطابق وسيطة عامل الإرساء بواسطة https://github.com/dotnet/core-setup/blob/master/build.sh#L36L37 خطوط. هل سبق لك أن قمت ببناء الإعداد الأساسي لـ Ubuntu.16.04-arm في عامل الإرساء؟ سطر أوامر البناء الخاص بي هو مثل أدناه. بعد التحليل في build.sh ، تتم إزالة بعض الوسائط.

./build.sh --docker ubuntu.16.04 --env-vars "DISABLE_CROSSGEN=1,TARGETPLATFORM=arm,TARGETRID=ubuntu.16.04-arm,CROSS=1,ROOTFS_DIR=/opt/code/cross/rootfs/arm"
->
Argumtens~~~~:--env-vars DISABLE_CROSSGEN=1,TARGETPLATFORM=arm,TARGETRID=-arm,CROSS=1,ROOTFS_DIR=/opt/code/cross/rootfs/arm

سأقوم بعمل العلاقات العامة قريبا. إذا كنت مخطئا ، أعلمني.

أنا فقط أقوم ببناءي من جهاز xenial VM ، ولم يشارك عامل Docker.

شكرا لتقاسم ديبيان softfp tarball! تمكنت من تشغيله على أحد الأنظمة الأساسية المضمنة التي أعمل بها عادةً (NI roboRIO لـ FRC). عملت بشكل خيالي ، وتمكنت حتى من تشغيل برنامج معقد إلى حد ما يعتمد على المقبس دون أي مشاكل يمكن أن أجدها. سيكون من اللطيف ألا تضطر إلى تخصيص Mono بعد الآن.

عملت بشكل خيالي ، وتمكنت حتى من تشغيل برنامج معقد إلى حد ما يعتمد على المقبس دون أي مشاكل يمكن أن أجدها

ThadHouse سعيد لسماع ذلك يساعد. وأيضًا لسماع أن التطبيقات المعقدة الحقيقية تعمل على dotnet for debian (softfp) في جهاز حقيقي :)

ThadHouse في الواقع لقد اختبرت العملية لـ debian.8-armel tarball على DockerImage باستخدام rpi3. إنه لأخبار جيدة حقًا أنها تعمل بشكل جيد على جهاز حقيقي. :)

@ gkhanna79 هل يمكن أن تخبرني بتقدم تحميل nupkg لـ arm في الإعداد الأساسي؟ AFAIK يجب أن يسبق ذلك ، يمكن تحميل CoreFX nupkgs إلى MyGet Feed. شكرا لدعمكم المتواصل.

jyoungyun لقد أجريت تصميمات تجريبية خلال عطلة نهاية الأسبوع وهي تبدو جيدة وتتوقع تشغيلها بحلول يوم الثلاثاء إذا سارت الأمور على ما يرام. سأبقي هذه المناقشة محدثة بالحالة.

إذا حصلت على حزم NuGet ، فسأكون سعيدًا بالمساعدة في اختبار إصدار debian.8.

لاحظ أنني لا أختبر في الواقع على نظام دبيان ، لكنه في الواقع نظام قوس. لكنه يحتوي على نفس sysroot ، أو قريب جدًا مما يمكنني قوله.

@ gkhanna79 خطئي : (يجب أن يكون تحميل CoreFX nupkgs متقدمًا على مهمة الإعداد الأساسي. ولقد وجدت CoreFX nupkgs لـ ARM في dotnet-core myget. شكرًا لك.

لدينا الآن إصداران Ubuntu 14.04 و 16.04 Arm32 يتم نشرهما يوميًا! إليك المجموعة الأولى من الحزم التي تم طرحها اليوم:

https://dotnet.myget.org/feed/dotnet-core/package/nuget/runtime.ubuntu.14.04-arm.Microsoft.NETCore.App/2.0.0-beta-001559-00

https://dotnet.myget.org/feed/dotnet-core/package/nuget/runtime.ubuntu.16.04-arm.Microsoft.NETCore.App/2.0.0-beta-001559-00

لدينا الآن إصداران Ubuntu 14.04 و 16.04 Arm32 يتم نشرهما يوميًا! إليك المجموعة الأولى من الحزم التي تم طرحها اليوم:

هذا عظيم! هل هناك خطط لبناء arm32 محمول؟ سيكون من الرائع تشغيل شبكة الإنترنت
راسبان ، فيدورا ، ... أيضًا.

tmds نعم ، نخطط للنظر في ذلك قريبًا.

هل هناك أي تصميم يمكنني استخدامه على Raspbian Pixel الآن؟ اليوم قمت بتحديث توزيعة الخاصة بي التي كسرت بطريقة ما أحادية اللون كنت أستخدمها حتى هذه النقطة. إذا لم يكن الأمر كذلك ، فهل هناك أي وقت مقدر للوصول إلى البنيات التي يمكن استخدامها في raspberry pi؟

TheRadziu لست متأكدًا مما إذا كان يعمل على بكسل raspbian بشكل صحيح أم لا ولكن https://dotnetcli.blob.core.windows.net/dotnet/master/Binaries/Latest/dotnet-ubuntu.16.04-arm.latest.tar .gz مخصص لـ ubuntu-mate (ubuntu.16.04-arm) وهو يعمل جيدًا على rpi3 الخاص بي مع ubuntu-mate.
يعتمد كل من raspbian و ubuntu-mate على Debian ، لذلك أعتقد أنه يمكنك تجربته مع raspbian أيضًا. إذا كانت هناك مشكلة في الإصدار ، فإن ubuntu.14.04-arm متاح أيضًا على https://dotnetcli.blob.core.windows.net/dotnet/master/Binaries/Latest/dotnet-ubuntu-arm.latest.tar.gz.

يمكنك العثور عليها في صفحة الإنشاء اليومية على https://github.com/dotnet/core-setup/.

hqueue شكرا لإجابتك! للأسف ، لا أستطيع أن أجعلها تعمل
./dotnet: /usr/lib/arm-linux-gnueabihf/libstdc++.so.6: version GLIBCXX_3.4.21 'غير موجود (مطلوب بواسطة ./dotnet) when I checked it by strings /usr/lib/arm-linux-gnueabihf/libstdc++.so.6 | تم إدراج grep GLIBCXX`it في GLIBCXX_3.4 حتى GLIBCXX_3.4.20 .
أتساءل عما إذا كان بإمكاني تحديثه بطريقة ما

TheRadziu يرجى تجربة ubuntu.14.04-arm على https://dotnetcli.blob.core.windows.net/dotnet/master/Binaries/Latest/dotnet-ubuntu-arm.latest.tar.gz

يبدو أن ubuntu.14.04-arm يتطلب 3.4 و 3.4.18 وليس 3.4.21.

TheRadziu @ hqueue fyi ، يحتوي glibc على ميزة التوافق مع الإصدارات السابقة. يتطلب بناء Linux x64 المحمول من dotnet glibc 2.14 كحد أدنى. سيكون لبناء arm32 المحمول متطلبات مماثلة.

@ gkhanna79 اكتشفت أن dotnet / core-setup # 789 (تمكين دعم بناء خط الأنابيب لنظام Linux Arm32) مغلق مؤخرًا للذراع.
هل يمكننا إضافة "Enable Pipeline build support for Linux Arm32" لـ armel (tizen) وإصدار إصدار جديد للعنصر؟ أخبرنا بخطتك لخط أنابيب Armel ، حتى نتمكن من مواكبة ذلك :)

hqueue نعم ، يُرجى إنشاء إصدار جديد (مخصص لي) لبناء خط أنابيب Tizen لكل من وحدات إعادة الشراء الثلاثة وإضافته إلى قائمة عناصر العمل لـ Tizen أعلاه.

@ gkhanna79 ماذا لديك خطة إصدار 2.0.0 حول sdk ؟ لا يمكنني حاليًا العثور على فرع لإصدار 2.0.0 في cli .

jyoungyun ، ألق نظرة على الفرع الرئيسي لـ cli repo.

hqueue @ hseok- ohjyoungyun على مدار الأسبوع الماضي ، قمت بتحويل تصميمات خطوط الأنابيب الرسمية لدينا لاستخدام _ubuntu1404_cross_prereqs_v2_ و _ubuntu1604_cross_prereqs_v2_ صور Docker التي تحتوي على مجموعة أدوات arm32 في _ / crossrootfs / arm_. هل يمكنك من فضلك النظر في تحديث البرامج النصية CI التي تضيفها / تضيفها لمعالجات CoreCLR / CoreFX / Core-Setup لاستخدامها وإزالة خطوة build-rootfs؟

@ gkhanna79 رائع! سنقوم بتحديث البرنامج النصي.

@ petermarcu شكرا لك!

أحاول إنشاء .NET Core Web API لـ Raspberry Pi 3 الذي يعمل بنظام التشغيل Ubuntu 16.04 مع وقت تشغيل 2x المتأخر. أنا أستخدم Visual Studio Code على نظام Windows الخاص بي عند التطوير. إصدار SDK الحالي الخاص بي هو 2.0.0-alpha-004853 ، ولكن عندما أقوم بعمل dotnet new webapi ، فإنه يضيف مراجع الحزمة هذه في ملف csproj الخاص بي:

<PackageReference Include="Microsoft.AspNetCore" Version="1.0.3" />
<PackageReference Include="Microsoft.AspNetCore.Mvc" Version="1.0.2" />
<PackageReference Include="Microsoft.Extensions.Logging.Debug" Version="1.0.1" />

لقد سمعت أن هذا هو سبب عدم تمكني من تشغيله عندما أحاول نشر الملف باستخدام dotnet publish --runtime ubuntu.16.04-arm . ربما توجد مشكلات أخرى قد أواجهها أيضًا.

أنا جديد تمامًا على كل هذا ، لذلك لست متأكدًا من خطوتي التالية. كيف يمكنني تضمين المتوافقة مع 2x؟ هل ما أحاول فعله ممكن في الوقت الحالي؟

challe يرجى تقديم مشكلة في CLI repo لدفع المناقشة هناك حول كيفية الحصول على CLI SDK الذي يدعم إطار عمل 2.0 (وهو قيد التطوير حاليًا).

سأفعل ذلك. شكرا.

مرحبًا ، حاولت تشغيل إصدار 1.0.0-preview5-004431 ولكنه لا يعمل. انها لا تعمل حتى مع مرحبا العالم. هل يمكن لأي شخص أن يخبرني إذا كان هناك أي نسخة صالحة للعمل يمكنني استخدامها؟ إذا كنت تستطيع ، يرجى نشر رابط التحميل. شكرا لك.

@ rahulreddy65 لنناقش هذا في https://github.com/dotnet/cli/issues/5868.

@ gkhanna79 الرجاء تطبيق عنصرين في صور عامل الإرساء في تحديث صور عامل الإرساء التالي.

• أضف x86 rootfs و toolchain في ubuntu1404 أو / و 1604 (وصورة عامل إرساء x86 جديدة للاختبار). نحن نستعد لبناء x86 linux CI.
• تطبيق dotnet / coreclr # 9897 في ubuntu1404 rootfs لإنشاء libcoreclrtraceptprovider.so

أقوم بإصدار إصدار جديد لصورة عامل الإرساء x86. دوت نت / كوريكلر # 9903.

@ gkhanna79 هل يمكنني معرفة متى يتم تحميل nupkgs tizen إلى خادم MyGet؟ أريد تمكين tizen CI في الإعداد الأساسي. و ... هل ستقوم بتحميل tarball ubuntu arm إلى خادم Azure؟ أحاول إنشاء cli لـ ubuntu arm ، لكن ذلك يعتمد على خادم Azure لتنزيل tarball في وقت التشغيل.

Ubuntu tarball متاح - راجع https://dotnetcli.blob.core.windows.net/dotnet/master/Binaries/Latest/dotnet-ubuntu.16.04-arm.latest.tar.gz. ألا يساعد هذا jyoungyun ؟

حسنا أرى ذلك. يمكنني استخدامه. توجد نفس كرة القطران على كلا المسارين أدناه. شكرا لك.
https://dotnetcli.blob.core.windows.net/dotnet/master
https://dotnetcli.azureedge.net/dotnet/master

@ gkhanna79 هل تريد تمكين ubuntu 16.04 arm CI افتراضيًا؟

jyoungyun هل هناك فرق كبير بين 14.04 و 16.04؟ IMHO ، ما لم نبدأ في رؤية المشكلات الفريدة الخاصة بها (والتي ستظهر على أنها فواصل بناء في خط الأنابيب الرسمي) ، يجب أن يكون وجود واحدة كافيًا. ما رأيك؟

hqueue هل أنا محق في افتراضي أن هذا الإصدار dotnet-debian.8-armel.1.2.0-beta-001271-00.tar.gz يجب أن يعمل على PI Zero Raspbian؟
لقد جربتها ولكن حصلت على خطأ تجزئة عند تنفيذ أمر dotnet. أي شيء يمكنني القيام به لحلها؟

لا أعتقد أنه يعمل على Pi Zero. لا أعتقد أن أي شخص قد نظر في السبب.

olegsavelos ، لن يعمل بناء debian.8-armel على صفر pi. جميع التصميمات هنا مخصصة لأجهزة armv7 ، مع اختيار الإصدارات المختلفة بين hard float ABI و soft float ABI. Pi Zero (و Pi الأصلي) هو جهاز armv6. لا أعرف ما الذي يتطلبه الأمر لتشغيل وبناء armv6 ، ولكن يمكن أن يتراوح من السهل إلى حد ما (تغيير أعلام المترجم) إلى الصعب للغاية. أنا فقط لا أعرف.

هل يمكن لأي شخص إلقاء بعض الضوء على دعم Armv6؟

jyoungyun ، هل سيعمل. net core tizen على صورة تتضمن https://github.com/TizenTeam/meta-tizen على yocto؟

olegsavelos إذا كنت تقصد PI Zero مع Broadcom BCM2835 ، أخشى أنه ليس من السهل العمل dotnet-debian.8-armel.1.2.0-beta-001271-00.tar.gz على Pi Zero. أتفق أيضًا مع ThadHouse على أن PI Zero يعتمد على armv6 ويمكن أن يتراوح من السهل إلى الصعب جدًا.

تستفيد شبكة AFAIK الحالية لـ ARM من Thumb-2 ISA التي لا تتوفر في ميزة armv6 و vfp والتي تتوفر في الغالب في armv7 ، ولكنها متاحة اختياريًا فقط في armv6. يدعم Armv6 الإبهام القديم وليس Thumb2 ، لذلك قد تضطر إلى إنشاء (1) كل المكونات الأصلية من dotnet لـ armv6 وأيضًا (2) قد تضطر إلى تحديث مترجم JIT والمكون الفرعي (مكتوب بلغة assmebly) من CoreCLR و CoreFX استخدام Thumb ISA وميزة vfp المدعومة من Broadcom BCM2835 بدلاً من armv7. لكن لا يمكنني تقدير مقدار الجهد المطلوب.

يبدو أن Mono تعمل بشكل جيد على armv6 ، لذا ألن يكون من الممكن نقل أجزاء التعليمات البرمجية المتعلقة بـ armv6 إلى .net core؟ على أي حال ، أعتقد أن PI Zero عبارة عن منصة ممتازة لمجموعة واسعة من الحلول وسيكون من العار عدم دعمها.

هل يمكن لأي شخص أن يخبرني متى سأتمكن من إنشاء برامج وتشغيلها على arm32 linux؟ شكرا

@ rahulreddy65 إذا كنت تستخدم Ubuntu 14.04 أو Ubuntu 16.04 لـ arm ، أعتقد أنه يمكنك تشغيل برامج C # على arm32 linux عن طريق تثبيت ثنائي من https://github.com/dotnet/core-setup#daily -builds.

• Ubuntu 14.04-arm https://dotnetcli.blob.core.windows.net/dotnet/master/Binaries/Latest/dotnet-ubuntu-arm.latest.tar.gz
• Ubuntu 16.04-arm https://dotnetcli.blob.core.windows.net/dotnet/master/Binaries/Latest/dotnet-ubuntu.16.04-arm.latest.tar.gz

إذا كنت تريد إنشاء برنامج C # من arm32 linux ، فهو غير متوفر بعد. ومع ذلك ، يمكنك إنشاء برنامج C # من بيئة أخرى ، مثل x64 linux أو x64 Windows ، وتشغيل البرنامج على Ubuntu arm.

وهناك طريقة أخرى يمكنك من خلالها إنشاء برنامج C # وتشغيله لـ arm32 linux مع إصدار إطار وقت التشغيل 2.0.0-beta-001620-00 والإصدارات الأحدث. يرجى إلقاء نظرة على https://github.com/dotnet/core/blob/master/samples/RaspberryPiInstructions.md
ومع ذلك ، فإنه يتطلب أيضًا بيئة x64 لإنشاء برنامج C #.

olegsavelos أعتقد أنه من الأفضل فتح مشكلة حول دعم armv6 على https://github.com/dotnet/coreclr ، لأن معظم الأعمال المطلوبة ذات صلة بـ coreclr والخبراء الذين يمكنهم الإجابة على أسئلتك (مثل دعم وحدة المعالجة المركزية الجديدة) هناك أيضا :)

@ hqueue شكرا! سوف نفعل ذلك :)

أخيرًا ، حصلت على أقل من النتائج !!!

pi3<strong i="6">@raspberry</strong>:~/Downloads/c$ time NUGET_PACKAGES=/home/pi3/Downloads/c/p dotnet build
Microsoft (R) Build Engine version 15.2.47.30403
Copyright (C) Microsoft Corporation. All rights reserved.

  c -> /home/pi3/Downloads/c/bin/Debug/netcoreapp2.0/c.dll

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

Time Elapsed 00:00:27.08

real    0m40.917s
user    0m43.890s
sys 0m1.390s

pi3<strong i="7">@raspberry</strong>:~/Downloads/c$ time NUGET_PACKAGES=/home/pi3/Downloads/c/p dotnet run
Hello World!

real    0m51.861s
user    0m54.380s
sys 0m1.870s

الأداء منخفض جدًا ، لكن Raspberry PI يمكنه إنشاء ملف cs نفسه!

jyoungyun هي هذه النتائج من إطلاق سراح بناء coreclr؟

janvorli تم تنزيل كل ملفات nupkg المستخدمة في بناء cli من خادم myget ، لذا فإن وقت التشغيل هذا (coreclr) هو إصدار للبناء بخيار -O1. إذا تم تمكين clang3.9 ، فستكون النتيجة أسرع. :)

jyoungyun تم اكتشافه في مشكلة أخرى أن الأمر dotnet run يضيف الكثير من الحمل إلى بداية التطبيق المُدار (على x64 Linux ، يضيف حوالي ثانيتين) مقارنة بتمرير التجميع المُدار مباشرة إلى dotnet بدون "تشغيل" .
هل يمكنك محاولة قياس هذه الحالة أيضًا؟ فقط لأكون واضحًا ، أعني تشغيل time dotnet /home/pi3/Downloads/c/bin/Debug/netcoreapp2.0/c.dll

janvorli في raspberry PI3 ، يكون تمرير dll كوسيطة مباشرة أسرع بحوالي 40 ثانية من استخدام dotnet run. يبدو أن هذا يمثل قدرًا كبيرًا من النفقات العامة في أمر تشغيل dotnet ...

pi3<strong i="7">@raspberry</strong>:~/Downloads/c$ time dotnet run
Hello World!

real    0m44.373s
user    0m56.000s
sys 0m1.800s

pi3<strong i="8">@raspberry</strong>:~/Downloads/c$ time dotnet /home/pi3/Downloads/c/bin/Debug/netcoreapp2.0/c.dll
Hello World!

real    0m1.389s
user    0m1.340s
sys 0m0.040s

jyoungyun شكرا لك على قياسه! نحن حقا بحاجة إلى القيام بشيء ما معها. سأضيف هذه المعلومات إلى المشكلة الأخرى حيث تم الإبلاغ عن البطء في x64.

janvorlijyoungyun أعتقد أن أحد الاختلافات الهائلة في timz يمكن أن يكون بسبب نقص الصورة الأصلية لـ arm cli ، والتي قد تكون متاحة لـ x64 cli نفسها.

حسنًا ، حتى على x64 ، هناك فرق كبير في هاتين الطريقتين لتشغيل التطبيق. انظر https://github.com/dotnet/cli/issues/6241

أرى الكثير من التقدم فيما يتعلق بـ Raspberry PI 2/3 و Ubuntu ... ولكن ما هو المطلوب لتشغيل مشروع dotnet core 2 الخاص بي على i.MX7 (Cortex-A7) مع نظام لينكس على أساس أنجستروم ؟

من خلال فهمي المحدود ، يجب أن تكون البنية هي armhf ، وهي الهندسة المعمارية الافتراضية في جميع أدلة تجميع البيانات عبر dotnet التي وجدتها حتى الآن.

لقد بدأت في التجميع المتقاطع CLR و FX ، ولكن يبدو أن كل شيء يتمحور حول أوبونتو. هل ستعمل النتيجة على أنجستروم ، طالما أن المتطلبات الأساسية المطلوبة (مثل libunwind ، إلخ) مثبتة؟

nzain - جرب التشغيل باستخدام Linux (armhf) (لنظام التشغيل المستند إلى glibc) في الجدول على core-setup-readme .
يعمل هذا بشكل جيد بالنسبة لنا (imx6 yocto poky) ولكن قد تضطر إلى إدخال التبعيات الأصلية إلى قائمة نظام التشغيل يدويًا.
لاحظ أيضًا أن dotnet / core-setup # 2358 لم يتم حلها بالكامل ، ولكن تم دمج الكود ، لذلك قد يكون السبب هو عدم التحقق من صحة الإصلاحات.

NET Core 2.0 يعمل بشكل لا تشوبه شائبة على Raspberry Pi 3 مع Raspbian Jessy Lite. ما يلي مطلوب لتشغيله:

عند تثبيت الفانيليا لتشغيل نظام التشغيل: sudo apt install libunwind8

في مشروع NET Core الخاص بك ، قم بما يلي:

<TargetFramework>netcoreapp2.0</TargetFramework>
<RuntimeIdentifiers>win10-x64;linux-arm</RuntimeIdentifiers>

للنشر على سطر الأوامر / vscode:

dotnet restore
dotnet build
dotnet publish --output Publish --runtime linux-arm

عندما يكون اسم مشروعك هو MyProject: انسخ جميع الملفات الموجودة في دليل النشر إلى Pi وقم بالتشغيل

chmod 744 MyProject
./MyProject

استمتع :)

hqueuejyoungyun هل يمكننا إغلاق هذه المشكلة لأن المشكلة المعلقة (حسب القائمة أعلاه) موجودة في CoreCLR repo ويتم تتبعها من خلال https://github.com/dotnet/coreclr/issues/8549؟

@ gkhanna79 بالتأكيد. سأضع علامة على https://github.com/dotnet/coreclr/issues/8549 في القائمة كما تم مع التعليق.

ستتم مناقشة إغلاق هذه المشكلة ومشكلات CoreCLR المتبقية على https://github.com/dotnet/coreclr/issues/8549