หนึ่งในนักพัฒนาของ Google ได้นำเสนอหัวข้อการพัฒนาในรายชื่ออีเมล LLVM ไลบรารี C มาตรฐานข้ามแพลตฟอร์ม (Libc) ภายใต้กรอบของโครงการ LLVM
ด้วยเหตุผลหลายประการ Google ไม่พอใจกับ libc ปัจจุบัน (glibc, มัสเซิล) และ บริษัท อยู่ในการติดตามเพื่อพัฒนาการใช้งานใหม่ซึ่งเขาตั้งใจที่จะพัฒนาเป็นส่วนหนึ่งของ LLVM เมื่อเร็ว ๆ นี้มีการใช้การพัฒนา LLVM เป็นพื้นฐานในการสร้างเครื่องมือของ Google
การพัฒนามีการวางแผนที่จะค่อยๆเพิ่มฟังก์ชันการทำงานทีละน้อย เสนอว่าตัวเลือกแรกจะอยู่ในรูปแบบของชั้นกลางระหว่างแอปพลิเคชันและระบบ libc ซึ่งจะมีการยืมคุณสมบัติที่ยังไม่เกิดขึ้นจริง
หลังจากใช้งานได้ถึงระดับหนึ่งแล้ว Libc ใหม่สามารถใช้แทนระบบ Libc ได้อย่างสมบูรณ์
มีการวางแผนที่จะเริ่มต้นด้วยการรองรับสถาปัตยกรรม x86-64, Linux และการผูกแบบคงที่ (การโหลดแบบไดนามิกบรรจุภัณฑ์และสถาปัตยกรรมเพิ่มเติมจะถูกนำมาใช้ในลำดับที่สอง)
โครงการยังอยู่ในขั้นตอนเริ่มต้นของการพัฒนา แต่ได้กำหนดวัตถุประสงค์พื้นฐานไว้แล้ว:
- ความเป็นโมดูลาร์และการพัฒนาตามปรัชญาของการจัดหาไลบรารีแบบละเอียดแทนที่จะเป็นวงดนตรีเสาหิน
- รองรับลิงก์แบบคงที่ในโหมด PIE (โปรแกรมปฏิบัติการที่ไม่ขึ้นกับตำแหน่ง) และไม่มี PIE จัดเตรียม CRT (รันไทม์ C) และตัวโหลด PIE สำหรับไฟล์ปฏิบัติการที่เชื่อมโยงแบบสแตติก
- รองรับฟังก์ชั่นไลบรารี C ส่วนใหญ่ มาตรฐานพร้อมปลั๊กอิน POSIX และส่วนขยายเฉพาะระบบบางส่วนที่ร้องขอในแอปพลิเคชันที่มีอยู่
- ทัศนคติที่รอบคอบต่อส่วนขยายที่เฉพาะเจาะจง จากผู้ให้บริการและเพิ่มเมื่อจำเป็นเท่านั้น สำหรับการสนับสนุนส่วนขยายของบุคคลที่สามขอเสนอให้ใช้แนวทางโครงการ Clang และ libc ++
- การใช้แนวทางปฏิบัติที่ดีที่สุดในการพัฒนาโดยใช้เครื่องมือ LLVMเช่นการใช้สารฆ่าเชื้อและการกำจัดการทดสอบตั้งแต่ต้น
หนึ่งในผู้พัฒนา LLVM ที่ใช้งานอยู่ระบุว่า การจัดส่ง libc เป็นส่วนหนึ่งของชุดเครื่องมือ LLVM มันไม่ได้ไร้ความหมาย แต่โดยทั่วไปแล้วด้วยความต้องการเช่นนี้พวกเขาจึงใช้ห้องสมุดมัสเซิล เขียนได้ดีรองรับสถาปัตยกรรมหลายแบบและมีฟังก์ชันการทำงานที่จำเป็นรวมถึงการเชื่อมโยงแบบไดนามิก
การรวม Musl เข้ากับ LLVM และการพัฒนาเป็นทางแยกที่ซิงโครไนซ์กับโครงการหลักสามารถเป็นธรรมได้
ความคิดเห็นของเขาถูกเปล่งออกมาโดยผู้เขียนโครงการ Musl ซึ่งพยายามโต้แย้งว่าทำไมข้อเสนอของ Google และการรวม Libc ในการส่ง LLVM จึงเป็นความคิดที่ไม่ดีมาก:
การพัฒนาและดูแล libc ที่ถูกต้องเข้ากันได้และมีคุณภาพสูงเป็นงานที่ยากมาก ปัญหาไม่ได้อยู่ที่จำนวนรหัส แต่อยู่ที่การให้พฤติกรรมที่ถูกต้อง
และความยากลำบากในการใช้งานอินเทอร์เฟซเมื่อพิจารณาจากพื้นที่เก็บข้อมูลขนาดใหญ่ของแอปพลิเคชันที่เขียนด้วย C / C ++ รวมถึงแอปพลิเคชันในภาษาอื่น ๆ ที่ Libc ใช้รันไทม์
การเข้าใกล้หน้าผากโดยไม่คำนึงถึงความแตกต่างจะนำไปสู่ความจริงที่ว่าโปรแกรมที่มีอยู่จำนวนมากจะไม่สามารถทำงานร่วมกับ Libc ได้ แต่โครงการดังกล่าวจะไม่เป็นที่สนใจของผู้บริโภค
การพัฒนาองค์กรสามารถทำลาย Libc ได้แต่กระตุ้นให้เกิดการใช้งานอย่างแพร่หลายซึ่งจะส่งผลให้ต้องเพิ่มแฮ็กเพื่อให้แน่ใจว่าเข้ากันได้กับแอปพลิเคชัน
การพัฒนาภายใต้การอุปถัมภ์ของโครงการขององค์กรแบบเปิดจะผลักดันความครอบคลุมไปสู่ความต้องการและการตัดสินใจของ บริษัท ไปจนถึงความเสียหายต่อผลประโยชน์ของชุมชน
ตัวอย่างเช่นในกรณีของการระบุปัญหาที่เกิดจากข้อผิดพลาดในโปรแกรมอื่นของคุณเองในการพัฒนาภายใต้การควบคุมการรับประกันความเข้ากันได้ของ Libc กับข้อผิดพลาดนี้ทำได้ง่ายกว่าการแก้ไขข้อผิดพลาดเอง
Apple ใช้ BSD libc fork เพื่อจุดประสงค์เหล่านี้และ Google ใช้ Fuchsia fork ประสบการณ์ของนักพัฒนาของ Musl ชี้ให้เห็นว่าทนายความติดต่อเขาเพื่อชี้แจงปัญหาการออกใบอนุญาตเป็นหลัก
Fuente: http://lists.llvm.org