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