ทำไม FreeBSD ถึงเลิกใช้ GCC เพื่อสนับสนุน Clang / LLVM

ดังนั้นผมท่องเน็ตและสะดุดเข้ากับบทความนี้ มันเป็นพื้นระบุว่าFreeBSDเริ่มต้นจากรุ่น 10 ขึ้นไปจะเลิกGCCในความโปรดปรานของเสียงดังกราว / LLVM

จากสิ่งที่ฉันได้เห็นรอบสุทธิเพื่อให้ห่างไกลเสียงดังกราว / LLVMเป็นโครงการที่มีความทะเยอทะยานอย่างเป็นธรรม แต่ในแง่ของความน่าเชื่อถือมันไม่สามารถจับคู่GCC

มีเหตุผลทางเทคนิคใดบ้างFreeBSD กำลังเลือก LLVM เป็นโครงสร้างพื้นฐานคอมไพเลอร์ของพวกเขาหรือไม่หรือว่าเรื่องทั้งหมดจะถูกนำไปใช้กับ GNU / GPL เทียบกับใบอนุญาต BSD นิรันดร์หรือไม่?

คำถามนี้มีข้อมูลที่เกี่ยวข้องเกี่ยวกับการใช้GCCในFreeBSD

สรุป: เหตุผลหลักในการเปลี่ยนจากGCCจะเสียงดังกราวคือความไม่ลงรอยกันของ GCC ของGPL v3ใบอนุญาตกับเป้าหมายของโครงการ FreeBSD นอกจากนี้ยังมีประเด็นทางการเมืองที่เกี่ยวข้องกับการลงทุนขององค์กรรวมถึงข้อกำหนดพื้นฐานของผู้ใช้ ในที่สุดก็มีข้อได้เปรียบทางเทคนิคที่คาดว่าจะทำกับการปฏิบัติตามมาตรฐานและความสะดวกในการแก้จุดบกพร่อง การปรับปรุงประสิทธิภาพในโลกแห่งความเป็นจริงในการรวบรวมและการดำเนินการเป็นรหัสเฉพาะและเป็นที่ถกเถียงกัน; สามารถสร้างเคสสำหรับคอมไพเลอร์ทั้งสอง

FreeBSD และ GPL: FreeBSDมีความสัมพันธ์ที่ไม่สบายใจกับ GPL สนับสนุน BSD ใบอนุญาตเชื่อว่าซอฟต์แวร์อิสระอย่างแท้จริงมีข้อ จำกัด การใช้งานไม่มี ผู้สนับสนุนของ GPL เชื่อว่าข้อ จำกัด มีความจำเป็นเพื่อปกป้องเสรีภาพของซอฟต์แวร์และโดยเฉพาะอย่างยิ่งความสามารถในการสร้างซอฟต์แวร์ที่ไม่ใช่ฟรีจากซอฟต์แวร์เสรีนั้นเป็นรูปแบบพลังงานที่ไม่ยุติธรรมแทนที่จะเป็นอิสระ โครงการ FreeBSD ที่เป็นไปได้พยายามหลีกเลี่ยงการใช้ GPL :

เนื่องจากความซับซ้อนเพิ่มเติมที่สามารถพัฒนาได้ในการใช้งานซอฟต์แวร์ GPL เชิงพาณิชย์เราจึงพยายามแทนที่ซอฟต์แวร์ดังกล่าวด้วยการส่งภายใต้ใบอนุญาต FreeBSD ที่ผ่อนคลายยิ่งขึ้นเมื่อใดก็ตามที่เป็นไปได้

FreeBSD และ v3 GPL: GPL v3อย่างชัดเจนห้ามที่เรียกว่าTivoisationของรหัสช่องโหว่ในv2 GPLซึ่งทำให้ข้อ จำกัด ของฮาร์ดแวร์ที่จะไม่อนุญาตให้มีการปรับเปลี่ยนซอฟต์แวร์ที่ถูกกฎหมายเป็นอย่างอื่นโดยผู้ใช้ การปิดช่องโหว่นี้เป็นขั้นตอนที่ยอมรับไม่ได้สำหรับหลาย ๆ คนในชุมชน FreeBSD:

ผู้ขายอุปกรณ์โดยเฉพาะอย่างยิ่งจะสูญเสียมากที่สุดหากปัจจุบันซอฟต์แวร์ขนาดใหญ่ที่ได้รับอนุญาตภายใต้ GPLv2 ในวันนี้ย้ายไปที่ใบอนุญาตใหม่ พวกเขาจะไม่มีอิสระในการใช้ซอฟต์แวร์ GPLv3 อีกต่อไปและ จำกัด การแก้ไขซอฟต์แวร์ที่ติดตั้งบนฮาร์ดแวร์ของพวกเขา ... ในระยะสั้นมีฐานลูกค้าขนาดใหญ่ของ OpenSource ที่จู่ ๆ ก็สนใจในการทำความเข้าใจกับซอฟต์แวร์ลิขสิทธิ์ GPL

เนื่องจากการย้าย GCC ไปยัง GPL v3 ทำให้ FreeBSD ถูกบังคับให้ใช้ GCC 4.2.1 (GPL v2) ซึ่งยังคงเปิดตัวในปี 2550และปัจจุบันล้าสมัยไปอย่างมาก ความจริงที่ว่า FreeBSD ไม่ได้ย้ายไปใช้ GCC รุ่นที่ใหม่กว่าแม้จะมีอาการปวดหัวเพิ่มเติมในการบำรุงรักษาคอมไพเลอร์และการแก้ไข backporting แต่ก็ให้ความคิดเกี่ยวกับความแข็งแกร่งของข้อกำหนดเพื่อหลีกเลี่ยง GPL v3 คอมไพเลอร์ C เป็นองค์ประกอบสำคัญของฐาน FreeBSD และ " หนึ่งในเป้าหมาย (ไม่แน่นอน) สำหรับ FreeBSD 10 คือระบบฐานที่ปราศจาก GPL "

การลงทุนของ บริษัท :เช่นเดียวกับโครงการโอเพ่นซอร์สที่สำคัญหลายโครงการ FreeBSD ได้รับเงินทุนและงานพัฒนาจาก บริษัท ต่างๆ แม้ว่าขอบเขตที่ FreeBSD จะได้รับทุนหรือรับการพัฒนาโดยแอปเปิ้ลไม่ได้ค้นพบได้ง่ายมีความคาบเกี่ยวกันเพราะแอปเปิ้ลดาร์วิน OSทำให้การใช้ BSD-เกิดขึ้นอย่างมีนัยสำคัญรหัสเคอร์เนล นอกจากนี้เสียงดังกราวตัวเอง แต่เดิมในบ้านแอปเปิ้ลโครงการก่อนที่จะถูกเปิดมาในปี 2007 เนื่องจากทรัพยากรขององค์กรเป็นกุญแจสำคัญของโครงการ FreeBSD ตอบสนองความต้องการสปอนเซอร์อาจจะเป็นคนขับรถที่แท้จริงของโลกอย่างมีนัยสำคัญ

Userbase: FreeBSD เป็นตัวเลือกโอเพ่นซอร์สที่น่าดึงดูดใจสำหรับหลาย ๆ บริษัท เพราะการออกใบอนุญาตนั้นง่ายไม่ จำกัด และไม่น่าจะนำไปสู่การฟ้องร้องได้ กับการมาถึงของ GPL v3 และใหม่บทบัญญัติป้องกัน Tivoisationจะได้รับการชี้ให้เห็นว่ามีการเร่งแนวโน้มของผู้ขายที่ขับเคลื่อนด้วยการต่อใบอนุญาตการอนุญาตเพิ่มเติม เนื่องจาก FreeBSD มีข้อได้เปรียบในเชิงการค้ากับหน่วยงานการค้าอยู่ในใบอนุญาตที่อนุญาตจึงมีแรงกดดันเพิ่มขึ้นจากฐานผู้ใช้องค์กรที่จะย้ายออกจาก GCC และ GPL โดยทั่วไป

ปัญหาเกี่ยวกับ GCC:นอกเหนือจากใบอนุญาตการใช้ GCC ยังมีปัญหาที่รับรู้อยู่บ้าง GCC ไม่ได้อย่างเต็มที่ตามมาตรฐานและมีหลายส่วนขยายที่ไม่พบในมาตรฐาน ISO C ด้วยโค้ดมากกว่า 3 ล้านบรรทัดมันเป็น " หนึ่งในโครงการซอฟต์แวร์โอเพนซอร์ซที่ซับซ้อนและฟรี / โอเพนซอร์ส " มากที่สุด ความซับซ้อนนี้ทำให้การแก้ไขรหัสระดับ distro เป็นงานที่ท้าทาย

ข้อได้เปรียบทางเทคนิค:เสียงดังกราวจะมีบางข้อได้เปรียบทางด้านเทคนิคเมื่อเทียบกับ GCC สิ่งที่น่าสังเกตมากที่สุดคือข้อความแสดงข้อผิดพลาดที่ให้ข้อมูลมากกว่าและAPI ที่ออกแบบมาอย่างชัดเจนสำหรับ IDEs การเปลี่ยนโครงสร้างและเครื่องมือในการวิเคราะห์ซอร์สโค้ด แม้ว่าเว็บไซต์ Clang จะแสดงพล็อตที่บ่งบอกถึงการรวบรวมและการใช้หน่วยความจำที่มีประสิทธิภาพมากขึ้น แต่ผลลัพธ์ในโลกแห่งความเป็นจริงนั้นมีความหลากหลายและสอดคล้องกับประสิทธิภาพของ GCC โดยทั่วไปไบนารีที่สร้างโดย Clang นั้นทำงานช้ากว่าไบนารี GCC ที่เทียบเท่า:

ในขณะที่ใช้ LLVM นั้นรวดเร็วกว่าการสร้างรหัสมากกว่า GCC ... ในกรณีส่วนใหญ่ไบนารีที่สร้างขึ้นของ GCC 4.5 ทำงานได้ดีกว่า LLVM-GCC หรือเสียงดังกราว ... ในส่วนที่เหลือของการทดสอบประสิทธิภาพนั้นใกล้เคียงกับ GCC หรือดี หลัง ในการทดสอบบางอย่างประสิทธิภาพของเสียงดังกราวที่สร้างโดยไบนารีนั้นแย่มาก

สรุป:ไม่น่าเป็นไปได้อย่างมากที่ประสิทธิภาพการรวบรวมจะเป็นตัวกระตุ้นสำคัญที่จะเสี่ยงต่อการย้ายโครงการขนาดใหญ่เช่น FreeBSD ไปยังเครื่องมือคอมไพเลอร์ใหม่ทั้งหมดโดยเฉพาะอย่างยิ่งเมื่อขาดประสิทธิภาพไบนารี อย่างไรก็ตามสถานการณ์ก็ไม่สามารถรักษาได้จริงๆ มีตัวเลือกระหว่าง 1) เรียกใช้ GCC ที่ล้าสมัย 2) การย้ายไปที่ GCC ที่ทันสมัยและถูกบังคับให้ใช้ใบอนุญาตที่ไม่สอดคล้องกับเป้าหมายของโครงการหรือ 3) การย้ายไปยังผู้รวบรวม BSD ที่มีเสถียรภาพการตัดสินใจ คงหนีไม่พ้น จำไว้ว่าสิ่งนี้ใช้ได้กับระบบฐานและการสนับสนุนจากการกระจายเท่านั้น ไม่มีอะไรป้องกันผู้ใช้จากการติดตั้งและใช้ GCC ที่ทันสมัยบนกล่อง FreeBSD ของพวกเขาเอง

สิ่งหนึ่งที่ควรพิจารณาคือ FreeBSD กำลังใช้ GCC 4.2.1 ดังที่ระบุไว้ในคำตอบ ire_and_cursesดังนั้นการเปรียบเทียบประสิทธิภาพไม่ได้อยู่ที่ 4.5 หรือ 4.6 แม้จะไม่เกี่ยวข้องกับโครงการจริงๆ ดังนั้นคำถามที่คุณควรถามคือ:

1. ประสิทธิภาพที่เพิ่มขึ้นของ Clang ใหม่กับ GCC ที่เก่ากว่าที่โครงการใช้คืออะไร

2. ไบนารีเดียวกันรวบรวมใน GCC 4.2.1 อย่างไรเมื่อเปรียบเทียบกับเสียงดังกราวใหม่

เนื่องจากการย้าย GCC ไปยัง GPL v3 ทำให้ FreeBSD ถูกบังคับให้ใช้ GCC 4.2.1 (GPL v2) ซึ่งยังคงเปิดตัวในปี 2550 และปัจจุบันล้าสมัยไปอย่างมาก

หากเสียงดังดังกล่าวไม่ทันกับ GCC ปัจจุบัน แต่ยังคงมีอีกไม่กี่ปีข้างหน้าของ GCC ที่ดำเนินการในโครงการการตัดสินใจของพวกเขาในการพัฒนานั้นได้รับการรับประกันอย่างดีและเป็นแรงบันดาลใจอย่างแท้จริง

แม้ว่า GCC เป็น GPLv3 แต่ไบนารีผลลัพธ์ที่สร้างโดย GCC ไม่เคยมีข้อ จำกัด สิทธิ์การใช้งานใด ๆ คุณสามารถใช้ GCC เพื่อสร้างซอฟต์แวร์ที่ตกอยู่ภายใต้ลิขสิทธิ์ที่คุณต้องการ แม้แต่ไลบรารี C ที่มาพร้อมกับ GCC และที่รวมอยู่ในไบนารีนั้นไม่มีใบอนุญาต http://www.gnu.org/licenses/gcc-exception-faq.html

ส่วนที่ 2 ของ GNU GPLv3:

คุณได้รับอนุญาตให้เผยแพร่งานของรหัสเป้าหมายที่เกิดขึ้นจากการรวม Runtime Library กับโมดูลอิสระแม้ว่าการเผยแพร่ดังกล่าวจะเป็นการละเมิดข้อกำหนดของ GPLv3 หากว่ารหัสเป้าหมายทั้งหมดถูกสร้างขึ้นโดยกระบวนการรวบรวมที่มีสิทธิ์ จากนั้นคุณสามารถถ่ายทอดชุดค่าผสมดังกล่าวภายใต้เงื่อนไขที่คุณเลือกซึ่งสอดคล้องกับการออกใบอนุญาตของโมดูลอิสระ

“ มีสิทธิ์” หมายความว่าการรวบรวมนั้นไม่เกี่ยวข้องกับซอฟต์แวร์ที่เข้ากันไม่ได้กับทั้ง GCC และ GPL นั่นไม่ใช่ข้อ จำกัด : ซอฟต์แวร์ที่มีลิขสิทธิ์ BSD สามารถใช้ในกระบวนการสร้างที่เกี่ยวข้องกับ GNU GCC

อย่างที่คุณเห็นว่าตรงกันข้ามกับสิ่งที่กล่าวข้างต้นไม่มีเหตุผลที่เกี่ยวข้องกับใบอนุญาตจริงที่จะย้ายออกจาก GCC เนื่องจากไม่มีความไม่ลงรอยกันกับการใช้ GCC ใน FreeBSD

เหตุผลที่แท้จริงที่อยู่เบื้องหลังการเปลี่ยนแปลงนี้คือเรื่องการเมืองและโอกาส:

• BSD มีสิทธิ์ใช้งานของตนเองซึ่งแข่งขันกับใบอนุญาตสาธารณะของ GNU ในเชิงปรัชญา (ดังที่ * ire_and_curses * อธิบายไว้ข้างต้น)
• CLANG เป็นคอมไพเลอร์ที่ไม่ใช่ GPL ใหม่ที่ริเริ่มโดยผู้สนับสนุนของ FreeBSD ที่ดูเหมือนจะเทียบเท่ากับ GCC ที่ได้รับใบอนุญาตด้านเทคนิค (ตามที่อธิบายข้างต้นโดย * ire_and_curses *)

ข้อเท็จจริงเหล่านี้สร้างโอกาสให้ FreeBSD ย้ายออกจาก GCC และกำจัดมัน: พวกเขาไม่ได้ถูกบังคับตามกฎหมายเพราะพวกเขายังสามารถใช้ GCC เพื่อสร้างซอฟต์แวร์ฟรีหรือลิขสิทธิ์ BSD ได้ แต่พวกเขาต้องการที่จะยึดติดกับ ปรัชญา "ซอฟต์แวร์ลิขสิทธิ์ BSD ทั้งหมด"

ฉันไม่มีความเชี่ยวชาญ แต่ความเข้าใจของฉันคือ Clang / LLVM ใช้ทรัพยากรน้อยกว่า GCC และเร็วกว่า

http://clang.llvm.org/features.html#performance

หากคุณใช้สภาพแวดล้อมที่คุณต้องการสร้างสิ่งต่างๆมากมายหลายครั้งประสิทธิภาพนั้นอาจเปลี่ยนเป็นการประหยัดพลังงานและเวลาอย่างแท้จริง ถ้าเป็นจริง