گوگل کان ڊولپرز مان هڪ LLVM ميلنگ لسٽ تي LLVM پروجيڪٽ جي حصي طور ملٽي پليٽ فارم معياري سي لائبريري (Libc) جي ترقي بابت. ڪيترن ئي سببن جي ڪري، گوگل موجوده libc (glibc، musl) کان مطمئن نه آهي ۽ ڪمپني هڪ نئين عمل درآمد ڪرڻ جي رستي تي آهي، جيڪا تجويز ڪيل آهي ته LLVM جي حصي طور ترقي ڪئي وڃي.
LLVM ترقيات تازو استعمال ڪيو ويو آهي بنياد جي طور تي گوگل جي اسيمبليء جي اوزار جي تعمير لاء. اصل خيال اهو آهي ته جيڪڏهن گوگل پنهنجي libc کي ترقي ڪرڻ شروع ڪري چڪو آهي ته پوءِ ڇو نه فوري طور تي پنهنجو سسٽم LLVM جي حصي طور ترقي ڪري، جيڪو اڳ ۾ ئي C++ (Libc++) لاءِ پنهنجي معياري لائبريري پيش ڪري ٿو، پر C لاءِ ساڳي معياري لائبريري نه آهي. (libc).
ترقي جي منصوبابندي ڪئي وئي آهي مرحلن ۾، تدريجي طور تي ڪارڪردگي وڌائڻ. پهرين اختيارن کي تجويز ڪيو ويو آهي ته ايپليڪيشن ۽ سسٽم Libc جي وچ ۾ هڪ پرت جي طور تي ڊزائين ڪيو وڃي، جنهن مان خاصيتون جيڪي اڃا تائين لاڳو نه ڪيا ويا آهن قرض ورتو ويندو. ڪارڪردگي جي هڪ خاص سطح تائين پهچڻ کان پوء، نئين Libc سسٽم لاء مڪمل متبادل طور استعمال ڪري سگهجي ٿو Libc. اسان x86-64 آرڪيٽيڪچر، لينڪس، ۽ جامد ڳنڍڻ جي حمايت سان شروع ڪرڻ جو منصوبو ٺاهيون ٿا (متحرڪ لوڊ ڪرڻ، ڳنڍڻ، ۽ اضافي تعميرات کي ثانوي طور تي لاڳو ڪيو ويندو).
پروجيڪٽ اڃا تائين ترقي جي شروعاتي مرحلي ۾ آهي، پر بنيادي مقصد اڳ ۾ ئي بيان ڪيا ويا آهن:
- ماڊولرٽي ۽ ڊولپمينٽ فلسفو جي مطابق هڪ گرينولر لائبريري پهچائڻ جي بدران هڪ واحد سيٽ جي ڀيٽ ۾؛
- موڊ ۾ جامد ڳنڍڻ لاءِ سپورٽ (پوزيشن-آزاد عملدار) ۽ بغير PIE. سي آر ٽي (سي رن ٽائم) ۽ پي آئي اي لوڊر فراهم ڪرڻ لاءِ جامد طور تي جڙيل عملدار؛
- معياري سي لائبريري جي اڪثر ڪمن لاءِ سپورٽ، POSIX اضافو ۽ موجوده ايپليڪيشنن لاءِ گهربل ڪجهه سسٽم-مخصوص واڌارن سان؛
- وينڊر-مخصوص واڌارن سان محتاط رھو ۽ صرف انھن کي شامل ڪريو جڏھن ضروري ھجي. ٽئين پارٽي جي توسيع جي حمايت جي حوالي سان، اها تجويز ڪيل آهي ته ڪلانگ ۽ libc++ منصوبن جي اپروچ کي استعمال ڪيو وڃي؛
- LLVM ٽول ڪٽ استعمال ڪندي ترقي ۾ بهترين طريقا استعمال ڪرڻ، جيئن ته شروع کان ئي صاف ڪرڻ وارو ۽ فز ٽيسٽنگ استعمال ڪرڻ.
فعال LLVM ڊولپرز مان هڪ اهو واضح آهي ته LLVM ٽول ڪٽ جي حصي طور libc موڪلڻ جو مطلب آهي، پر عام طور تي، جڏهن اهڙي ضرورت پيدا ٿئي ٿي، اهي مسل لائبريري استعمال ڪندا آهن، جيڪا چڱي طرح لکيل آهي، مختلف فن تعمير کي سپورٽ ڪري ٿي، ۽ ضروري ڪارڪردگي مهيا ڪري ٿي، بشمول متحرڪ لاء سپورٽ. ڳنڍڻ. اهو جواز ٿي سگهي ٿو ته مسل کي LLVM ۾ شامل ڪيو وڃي ۽ ان کي مکيه منصوبي سان هم وقت سازي واري ڪانٽو جي طور تي ترقي ڪريو.
توهان جي راء پڻ مسل پروجيڪٽ جو مصنف، جنهن بحث ڪرڻ جي ڪوشش ڪئي ڇو ته گوگل جي تجويز ۽ ايل ايل وي ايم جي تقسيم ۾ ليبڪ جي شموليت تمام خراب خيال آهن:
- هڪ درست، مطابقت رکندڙ، ۽ اعلي معيار جي Libc کي ترقي ۽ برقرار رکڻ هڪ تمام ڏکيو ڪم آهي. مسئلو ڪوڊ جي مقدار ۾ نه آهي، پر انٽرفيس کي لاڳو ڪرڻ ۾ صحيح رويي ۽ مشڪلاتن کي يقيني بڻائڻ ۾، ايپليڪيشنن جي وڏي پرت کي نظر ۾ رکندي ڪڏهن به C/C++ ۾ لکيل آهي، انهي سان گڏ ٻين ٻولين ۾ ايپليڪيشنون، جن جو رن ٽائيم استعمال ڪيو ويندو آهي. Libc پاران. nuances جي اڪائونٽ ۾ وٺڻ کان سواء هڪ سر-تي-طريقو صرف حقيقت اها آهي ته ڪيترن ئي موجود پروگرامن Libc سان ڪم ڪرڻ جي قابل نه ٿيندو، پر پوء اهڙي منصوبي صارفين لاء دلچسپي نه هوندي.
- ڪارپوريٽ ڊولپمينٽ Libc کي تباهه ڪري سگهي ٿي، پر ان کي وڏي پيماني تي استعمال ڪرڻ لاءِ زور ڏئي سگهي ٿو، جنهن جي نتيجي ۾ ايپليڪيشنن ۾ مطابقت کي يقيني بڻائڻ لاءِ هيڪس شامل ڪرڻ جي ضرورت آهي. هڪ ڪارپوريٽ اوپن سورس پروجيڪٽ جي سرپرستي هيٺ ترقي، ڪمپني جي ضرورتن ۽ حلن جي طرف، ڪميونٽي جي مفادن کي نقصان پهچائيندو. مثال طور، جيڪڏهن توهان ڪنهن مسئلي جي نشاندهي ڪريو ٿا جيڪو ڪنهن ٻئي پروگرام ۾ بگ جي ڪري پيدا ٿئي ٿو، ڪنٽرول ٿيل ڊولپمينٽ ۾ اهو پڪ ڪرڻ آسان آهي ته Libc هن بگ سان مطابقت رکي ٿو ان کان سواءِ پاڻ بگ کي درست ڪرڻ. ايپل انهن مقصدن لاءِ BSD libc فورڪ استعمال ڪري ٿو، ۽ گوگل فوڪسيا ۾ مسل فورڪ استعمال ڪري ٿو. مسل ڊولپر جو تجربو اهو آهي ته هن سان خاص طور تي وڪيلن طرفان لائسنس جي مسئلن کي واضح ڪرڻ لاءِ رابطو ڪيو ويو، پر هن سان ڪڏهن به رابطو نه ڪيو ويو ته جيئن هن جي برانچن ۾ بيڪار ۽ تباهي واري تبديليون ڪرڻ کان اڳ ٽيڪنيڪل تفصيلن کي واضح ڪيو وڃي.
- libc ڊولپمينٽ ۾ مونو ڪلچر جي غير موجودگي ۽ انفرادي ڪنٽرول جي بجاءِ اتفاق سان هلندڙ معيارن تي ڌيان ڏيڻ، جيڪو ايپليڪيشن ڊولپرز کي حوصلا افزائي ڪري ٿو ته معيار کي استعمال ڪرڻ بجاءِ مخصوص عملن سان ڳنڍجي. اهو ئي سبب آهي ته مسل جو مصنف پنهنجي لائبريريءَ کي LLVM ۾ شامل ڪرڻ جي خلاف آهي، ۽ گڏوگڏ LLVM اندر libc جي ترقيءَ جي خلاف آهي، ڇاڪاڻ ته ان صورت ۾ libc جي آزاد طبيعت ختم ٿي ويندي آهي ۽ هڪ خاص عمل درآمد لاءِ فرسٽ ڪلاس حل بڻجي ويندو آهي. LLVM، ۽ ٻيا سڀ هڪ سيڪنڊ-ڪلاس حل بڻجي ويا.
جو ذريعو: opennet.ru