قدم أحد مطوري Google موضوع التطوير على القائمة البريدية لـ LLVM مكتبة C قياسية عبر الأنظمة الأساسية (Libc) في إطار مشروع LLVM.
لعدة أسباب، Google غير راضٍ عن libc الحالي (glibc، musl) والشركة في طريقها لتطوير تطبيق جديد، والذي ينوي تطويره كجزء من LLVM. تم استخدام تطورات LLVM مؤخرًا كأساس لبناء أدوات Google.
تم التخطيط للتطوير ليكون تدريجيًا ، وزيادة الوظائف تدريجياً. يُقترح أن تأخذ الخيارات الأولى شكل طبقة وسيطة بين التطبيق ونظام libc ، والتي سيتم استعارة الميزات غير المحققة منها.
بعد الوصول إلى مستوى معين من الوظائف ، يمكن استخدام Libc الجديد كبديل كامل لنظام Libc.
من المخطط البدء بدعم بنية x86-64 و Linux والربط الثابت (سيتم تنفيذ التحميل الديناميكي والتعبئة والبنى الإضافية ثانيًا).
لا يزال المشروع في المرحلة الأولى من التطوير ، لكن الأهداف الأساسية قد تم تحديدها بالفعل:
- نمطية وتطوير وفقًا لفلسفة توفير مكتبة حبيبية، بدلا من مجموعة متجانسة.
- دعم الارتباط الثابت في أوضاع PIE (ملفات تنفيذية مستقلة عن الموضع) وبدون PIE. توفير CRT (C Runtime) ومحمل PIE للملفات القابلة للتنفيذ المرتبطة بشكل ثابت.
- يدعم معظم وظائف مكتبة C. قياسي مع المكونات الإضافية POSIX وبعض الامتدادات الخاصة بالنظام المطلوبة في التطبيقات الحالية.
- موقف حذر تجاه امتدادات محددة من الموفر وإضافتها فقط عند الضرورة. لدعم تمديد الطرف الثالث ، يُقترح استخدام نهج مشروع Clang و libc ++.
- استخدام أفضل الممارسات في التطوير باستخدام أدوات LLVM، مثل استخدام المطهرات وإزالة الأدلة من البداية.
أشار أحد مطوري LLVM النشطين إلى ذلك تسليم libc كجزء من مجموعة أدوات LLVM لا يخلو من المعنى ، ولكن بشكل عام مع هذه الحاجة يستخدمون مكتبة Musl ، إنه مكتوب جيدًا ، ويدعم العديد من البنى ، ويوفر الوظائف الضرورية ، بما في ذلك الارتباط الديناميكي.
يمكن تبرير دمج Musl في LLVM وتطويره كشوكة متزامنة مع المشروع الرئيسي.
تم التعبير عن رأيه أيضًا من قبل مؤلف مشروع Musl ، الذي حاول أن يجادل لماذا يعتبر اقتراح Google وإدراج Libc في تسليم LLVM أفكارًا سيئة للغاية:
يعد تطوير libc الصحيح والمتوافق والعالي الجودة والمحافظة عليه مهمة صعبة للغاية. المشكلة ليست في مقدار الكود ، ولكن في توفير السلوك الصحيح.
والصعوبات في تنفيذ الواجهة ، مع الأخذ في الاعتبار المخزون الضخم للتطبيقات المكتوبة بلغات C / C ++ ، وكذلك التطبيقات بلغات أخرى والتي يستخدم Libc وقت تشغيلها.
إن نهج الجبهة دون مراعاة الفروق الدقيقة لن يؤدي إلا إلى حقيقة أن العديد من البرامج الحالية لن تكون قادرة على العمل مع Libc ، ولكن مثل هذا المشروع لن يكون موضع اهتمام المستهلكين.
يمكن أن يؤدي تطوير الشركات إلى تدمير شركة Libc، ولكن استخدام واسع النطاق ، مما سيؤدي إلى الحاجة إلى إضافة الاختراقات لضمان التوافق في التطبيقات.
التطوير تحت رعاية مشروع مؤسسي مفتوح سيدفع التغطية نحو احتياجات وقرارات الشركة ، على حساب مصالح المجتمع.
على سبيل المثال ، في حالة تحديد مشكلة ناتجة عن خطأ في برنامج آخر خاص بك ، في التطوير تحت السيطرة ، يكون من الأسهل ضمان توافق Libc مع هذا الخطأ بدلاً من تصحيح الخطأ نفسه.
تستخدم Apple شوكة BSD libc لهذه الأغراض وتستخدم Google شوكة Fuchsia. تشير تجربة مطور Musl إلى أن المحامين اتصلوا به في المقام الأول لتوضيح مشكلات الترخيص.
مصدر: http://lists.llvm.org