GCC-आधारित Rust compiler के विकास में प्रगति

 (lwn.net)
2 पॉइंट द्वारा GN⁺ 2023-12-19 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • gccrs 2014 में शुरू हुआ एक प्रोजेक्ट है जिसका लक्ष्य GCC के भीतर Rust compiler को implement करना है। यह अभी पूर्ण होने से काफी दूर है, लेकिन standard library compile करने और GCC 14 में शामिल होने की दिशा में प्रगति हुई है
  • प्रोजेक्ट ने तेज़ी से बदलते नए Rust versions का पीछा करने के बजाय Rust 1.49 को लक्ष्य बनाया, लेकिन standard library की आंतरिक dependencies के कारण अंततः const generics जैसी features भी implement करनी पड़ीं
  • core और alloc का compilation अभी macro name resolution, decorator macro, GCC में अनुपस्थित LLVM compiler intrinsic, और borrow checker की कमी के कारण अटका हुआ है
  • rustc_codegen_gcc एक अधिक परिपक्व तरीका है, जो rustc के कुछ हिस्सों का उपयोग करता है और backend code generation के लिए GCC का इस्तेमाल करता है; अक्टूबर 2023 तक यह बिना अतिरिक्त patch के Rust for Linux को compile कर सकता है
  • gccrs के पीछे GCC security plugins, static analysis, LLVM द्वारा असमर्थित architectures, और Rust for Linux जैसी स्पष्ट प्रेरणाएँ हैं, लेकिन व्यावहारिक उपयोगिता अभी rustc_codegen_gcc की तुलना में सीमित है

gccrs का लक्ष्य और मौजूदा स्थिति

  • gccrs एक ऐसा प्रोजेक्ट है जिसका उद्देश्य GNU Compiler Collection(GCC) के भीतर Rust compiler को implement करना है
  • इसकी शुरुआत 2014 में हुई थी, और LWN की पिछली कवरेज के बाद प्रोजेक्ट रिपोर्ट के अनुसार इसमें प्रगति हुई है
  • 2022 में इसका लक्ष्य GCC 13 में शामिल होना था, लेकिन यह हासिल नहीं हो सका; नवंबर 2023 की मासिक रिपोर्ट के अनुसार अब लक्ष्य GCC 14 में शामिल होना है
    • GCC 14 को 2024 के मध्य में जारी होने वाले संस्करण के रूप में देखा जा रहा था
  • अक्टूबर 2023 के EuroRust 2023 में Arthur Cohen ने “The road to compiling the standard library with gccrs” शीर्षक से प्रस्तुति दी, जिसमें Rust standard library को compile करने के काम और अब तक compile न हो पाने के कारणों की व्याख्या की गई

Rust 1.49 को लक्ष्य बनाने का कारण

  • gccrs लगातार Rust के नवीनतम संस्करण का पीछा करने के बजाय Rust 1.49 को लक्ष्य बनाता है
  • Rust 1.49 2020 के अंत में रिलीज़ हुआ था, और यह उस support से पहले का अंतिम संस्करण था जिसमें const generics Rust 1.50 में सामान्य उपयोग के लिए उपलब्ध हुआ
  • प्रोजेक्ट const generics से बचना चाहता था, लेकिन Rust 1.49 की standard library के अंदर भी इसका उपयोग पहले से हो रहा था, इसलिए इसे नज़रअंदाज़ नहीं किया जा सका
  • बाद में const generics पूरी तरह implement कर दिया गया, और अब यह बाधा नहीं है
  • gccrs Rust का कोई superset या अलग “GNU Rust” भाषा बनाना नहीं चाहता
    • इसका लक्ष्य rustc के output, bugs, और अजीब व्यवहार तक को reproduce करना है
    • इसके लिए यह Rust test suite और GCC test suite दोनों का उपयोग करता है

standard library compilation में अटके हिस्से

  • Rust standard library कई crate से बनी होती है
  • gccrs सबसे महत्वपूर्ण दो crates core और alloc के compilation support पर काम कर रहा है
    • core primitive types और macros जैसी standard library की बुनियादी सुविधाएँ implement करता है
    • alloc heap memory allocation और कई container types को संभालता है
  • फिलहाल gccrs नीचे दी गई क्षमताओं की कमी के कारण इन crates को compile नहीं कर पा रहा है
    • macro name resolution सही तरह काम नहीं कर रही
    • decorator macro support अधूरा है
    • borrow checker नहीं है, इसलिए code safety की ठीक से जाँच नहीं हो पाती
    • GCC में अनुपस्थित LLVM compiler intrinsic को implement करना होगा
  • borrow checker की अनुपस्थिति compilation को सीधे नहीं रोकती, लेकिन यह Rust code की safety जाँच को सही ढंग से करने से रोकती है

procedural macro और GCC integration का काम

  • सितंबर 2023 के GNU Tools Cauldron में Pierre-Emmanuel Patry ने GCC 14 में शामिल होने की प्रगति और macro संबंधी काम पर केंद्रित प्रस्तुति दी
  • procedural macro को implement करने के लिए GCC build system में बदलाव की आवश्यकता होती है
  • procedural macro, C या C++ macros की तरह सिर्फ source text नहीं निकालते, बल्कि token stream आउटपुट करने वाले functional macros होते हैं
  • Rust में इन्हें built-in crate proc_macro के ज़रिए implement किया जाता है
  • procedural macro implement करना कठिन है, लेकिन यह शक्तिशाली सुविधाएँ संभव बनाते हैं
    • #[attribute] decorator
    • #[derive()] decorator
    • compile-time evaluation पर आधारित domain-specific language generation
  • GNU Cauldron प्रस्तुति के समय gccrs में 800 से अधिक commits थे जिन्हें GCC में upstream किया जाना बाकी था

GCC ecosystem को Rust में इस्तेमाल करने का कारण

  • gccrs की मुख्य प्रेरणाओं में से एक Rust code पर भी GCC के security plugins का उपयोग करना है
  • GCC में debugging, static analysis, और hardening में मदद करने वाले कई plugins हैं, और ये GCC intermediate representation पर काम करते हैं
  • gccrs ऐसा workflow support करना चाहता है जिसमें Rust developer मौजूदा GCC plugins का पुन: उपयोग कर सकें
  • Cohen ने उदाहरण दिया कि C programmers लंबे समय से file descriptor बंद करना भूलते रहे हैं, इसलिए ऐसी गलतियों को पकड़ने वाले plugins बहुत हैं
  • लक्ष्य यह है कि Rust के unsafe code में bugs पकड़ने के लिए मौजूदा GCC plugins और static analyzers का उपयोग किया जा सके

जहाँ इसका कुछ उपयोग पहले से हो रहा है

  • Cohen के अनुसार Sega Dreamcast homebrew community gccrs का उपयोग करके Dreamcast game console के लिए नए games बना रही है
  • Dreamcast community की रुचि का कारण यह है that rustc का LLVM backend console की Hitachi SH-4 architecture को support नहीं करता, जबकि GCC करता है
  • gccrs अभी अधूरा है, लेकिन ऐसे embedded use cases में यह उपयोगी है
  • GCC plugins के माध्यम से unsafe Rust code की static analysis पहले से संभव है
  • gccrs पर काम करते हुए Deref और macro name resolution जैसी language features सामने आईं जिनकी specification पर्याप्त स्पष्ट नहीं थी, और प्रोजेक्ट Rust specification में योगदान भी दे सका
    • Rust की अभी कोई आधिकारिक specification नहीं है, लेकिन RFC 3355 के अनुसार इस पर काम चल रहा है

अब भी विकासाधीन मुख्य सुविधाएँ

  • gccrs में अभी भी Rust compiler की कई मुख्य सुविधाएँ नहीं हैं
  • प्रमुख unimplemented या development में चल रही सुविधाएँ ये हैं
    • async/await
    • GCC में अनुपस्थित LLVM intrinsic
    • println!() जैसे output macros द्वारा इस्तेमाल किया जाने वाला format_args!() macro
    • Rust reference rules लागू करने वाला borrow checker
  • borrow checker के लिए सबसे संभावित समाधान अलग प्रोजेक्ट Polonius है
  • Cohen ने कहा कि gccrs आने वाले कुछ महीनों में Polonius को integrate कर सकता है
  • Jakub Dupak ने पिछले कुछ महीनों में इस काम में प्रगति की है
  • Polonius फिलहाल एक ऐसी library है जो rustc के borrow checker के अर्थ की दृष्टि से समतुल्य borrow checker implement करती है
    • यह reference lifetimes की गणना के लिए एक अलग algorithm का उपयोग करती है
    • लंबी अवधि में इसका लक्ष्य rustc के मौजूदा borrow checker की कमियाँ और corner cases को हल करना है
    • परिपक्व होने पर भविष्य में rustc भी Polonius को अपना सकता है

format_args!() की आवश्यकता क्यों है

  • नवंबर 2023 की gccrs मासिक रिपोर्ट के अनुसार format_args!() macro पर काम शुरू हो गया है
  • format_args!() एक helper macro है जो string formatting macros को दिए जाने वाले arguments तैयार करता है
  • यह सुविधा Display और Debug traits से जुड़ी है
  • format!() और println!() जैसे macros को दिए जाने वाले arguments तैयार करने के लिए यह ज़रूरी है
  • format_args!() के बिना Rust program formatted output नहीं बना सकता
  • इसलिए gccrs के लिए “Hello, World” program compile करने से पहले भी यह सुविधा आवश्यक है
  • format_args!() की गहराई से व्याख्या के लिए Mara Bos की blog post का भी उल्लेख किया गया

rustc_codegen_gcc से अंतर

  • rustc_codegen_gcc gccrs से अलग GCC-आधारित Rust प्रोजेक्ट है
  • यह gccrs से अधिक परिपक्व है, लेकिन इसका दायरा अधिक सीमित है
  • यह Rust compiler को शुरू से पूरी तरह implement करने का तरीका नहीं अपनाता
  • यह libgccjit library का उपयोग करके rustc के LLVM backend API से जुड़ता है
  • compilation का बड़ा हिस्सा rustc करता है, और बाद के चरणों में GCC का उपयोग होता है
  • libgccjit नाम में JIT होने के बावजूद, rustc_codegen_gcc का लक्ष्य ahead-of-time compilation है
  • इसका मुख्य उद्देश्य उन platforms पर Rust code generation संभव बनाना है जिन्हें LLVM support नहीं करता
  • अक्टूबर 2023 तक rustc_codegen_gcc बिना अतिरिक्त patch के Rust for Linux को compile कर सकता है
  • पिछले एक वर्ष में इसमें SIMD और link-time optimization support जोड़ा गया
    • इन दोनों सुविधाओं को पहले test failures का कारण बताया गया था
  • Cohen ने EuroRust प्रस्तुति में कई बार सलाह दी कि फिलहाल gccrs के बजाय rustc_codegen_gcc का उपयोग किया जाए
  • rustc_codegen_gcc पहले से upstream Rust repository में शामिल है

Rust for Linux और version gap

  • Rust for Linux Linux kernel में Rust support जोड़ने की पहल है
  • Cohen ने Linux kernel को gccrs प्रोजेक्ट की मुख्य प्रेरणा बताया
    • क्योंकि kernel से जुड़े कई लोग चाहते हैं कि kernel केवल GNU toolchain से compile हो
  • फिलहाल Rust for Linux प्रोजेक्ट kernel Rust code build करने के तरीके के रूप में rustc या rustc_codegen_gcc को document करता है
  • kernel में कई build tools के minimum supported versions का documentation भी है
    • rustc को minimum version की तरह नहीं, बल्कि एक exactly matching version की तरह माना जाता है
    • वर्तमान में supported rustc version अक्टूबर 2023 में रिलीज़ हुआ 1.73.0 है
  • gccrs जिस Rust 1.49 को लक्ष्य बना रहा है और Rust for Linux को जिस Rust 1.73.0 की आवश्यकता है, उनके बीच बड़ा अंतर है
  • Rust for Linux support gccrs का घोषित लक्ष्य है, लेकिन इस version gap के कारण वह अभी काफी दूर है

समग्र मूल्यांकन

  • gccrs repository में 1 जनवरी 2023 के बाद से 3,000 से अधिक commits हैं
  • पिछले एक वर्ष में प्रोजेक्ट ने उल्लेखनीय प्रगति दिखाई है
  • लेकिन शुरू से एक पूर्ण Rust compiler implement करने का दायरा बहुत बड़ा होने के कारण, लगभग सभी व्यावहारिक उद्देश्यों के लिए यह अभी उपयोग योग्य स्थिति में नहीं है
  • rustc_codegen_gcc upstream Rust repository में merge हो चुका है और Rust for Linux में वास्तविक उपयोग में है
  • Rust language में कई स्वतंत्र compiler implementations मौजूद होने वाले चरण तक अभी पहुँचा नहीं गया है, लेकिन दिशा उसी ओर बढ़ रही है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2023-12-19
Hacker News की राय

  • सिर्फ़ लेख के दावे के आधार पर gccrs की प्रेरणा कुछ कमज़ोर लगती है
    GCC security plugin या Linux kernel की GNU toolchain पसंद यह समझाती है कि GCC को backend के रूप में क्यों इस्तेमाल करना चाहेंगे, लेकिन यह नहीं बताती कि duplicate frontend की ज़रूरत क्यों है
    उम्मीद है Rust, C++ जैसी वही गलती नहीं दोहराएगा जहाँ कई compilers के switches, language support level के फ़र्क, और platform-specific bugs की वजह से cross-platform development मुश्किल हो जाता है
    इसलिए अच्छा होता अगर यह बताया जाता कि gccrs, rustc_codegen_gcc से बेहतर तरीका क्यों है; बाद वाला बहुत कम मेहनत और कम जोखिम में वही लक्ष्य हासिल करता हुआ दिखता है

    • Rust का एक और implementation होना, Rust spec को verify करने और undefined behavior कम करने के लिए audit की तरह काम कर सकता है
      MSVC में compiler bug मिलने पर उसे report करके GCC पर switch कर काम जारी रखा जा सकता है, लेकिन Rust में अभी ऐसा कोई विकल्प नहीं है
    • Rust, C++ की गलतियों से पहले ही सीख रहा है
      जैसे उद्धरण में कहा गया, इसका उदाहरण यह सावधानी है कि वह Rust का superset न बन जाए
      C/C++ की समस्या इस वजह से भी बनी कि compiler vendors एक-दूसरे से “और बेहतर” होने की होड़ करते रहे, और कई frontends का फ़ायदा यह होता है कि वे अक्सर bugs और ग़लत implementations को ज़्यादा उजागर करते हैं
    • समझ नहीं आता कि यह सवाल बार-बार क्यों उठता है
      ऐसा नहीं है कि Rust किसी मायने में पवित्र है और frontend rewrite पर रोक है, और नई architecture पर Rust को bootstrap करना अब भी काफ़ी दर्दनाक है
      जिन architectures को LLVM support नहीं करता, उनके लिए कोई काम करने वाला Rust compiler भी नहीं है
      codegen_rust_gcc में भी मौजूदा Rust compiler जैसा ही bootstrap problem है, और Rust के कई हिस्सों में architecture support जोड़ना पड़ता है, जिसे Rust maintainers अब तक टालते रहे हैं
      इसलिए अगर निकट भविष्य में ऐसा Rust compiler मिल जाए जिसे तुरंत इस्तेमाल किया जा सके, तो Alpha जैसी architecture पर भी फिर से Rust-आधारित libraries को बिना बहुत परेशानी के build किया जा सकेगा, और यह बहुत स्वागतयोग्य होगा
    • उसी तर्क से फिर यह भी पूछना पड़ेगा कि LLVM community ने DragonEgg पर टिके रहने के बजाय Clang, Clang++, libc++ क्यों बनाए
      पहले से GCC, G++, libstdc++, और EDG C++ frontend मौजूद थे
      GCC, Clang, MSVC और दूसरे compilers एक-दूसरे को पूरक बनाते हैं, अलग-अलग उद्देश्यों और बाज़ारों की ज़रूरतें पूरी करते हैं, और भाषा को किसी एक implementation की आकस्मिक विशेषता बनने के बजाय spec के अनुरूप मज़बूत बनाते हैं
      GNU Toolchain Project, LLVM Project, और Rust project — सभी ने समस्याएँ देखी हैं, इसलिए single point of failure पर निर्भर न रहना बेहतर है, और redundancy और antifragility हमारे दोस्त हैं
    • जब कहा जाता है कि Rust को C++ और C की गलतियों से सीखना चाहिए, तो क्या उसका मतलब यह है कि इतिहास की सबसे लंबे समय तक टिकने वाली, सबसे प्रभावशाली और सबसे व्यापक रूप से वितरित भाषाओं की गलतियों से सीखना चाहिए?
      language standard को बुरा मानना, और “यह code C99/C++11 है” कहने के बजाय “यह code SHA256 hash e49d560cd008344edf745b8052ef714b07595808898c835f17f962a10012f964 वाले rustc binary/source पर चलता है” कहना, काफ़ी उलझाने वाला लगता है

  • Rust को language standard की ज़रूरत है
    https://blog.m-ou.se/rust-standard/
    https://rust-lang.github.io/rfcs/3355-rust-spec.html
    https://github.com/rust-lang/rfcs/pull/3355
    standard बनने से पहले कई organizations और industries Rust नहीं अपनाएँगी
    C, C++, C#, यहाँ तक कि JavaScript (ECMAScript) की भी language standard है, तो Rust के पास न होने की कोई वजह नहीं है
    C: https://www.iso.org/standard/74528.html
    C++: https://isocpp.org/std/the-standard
    C#: https://learn.microsoft.com/en-us/dotnet/csharp/language-ref...
    JavaScript / ECMAScript: https://ecma-international.org/publications-and-standards/st...

    • वह RFC पहले ही approve हो चुका है, और उस पर वास्तविक काम शुरू भी हो चुका है
      प्रगति निराशाजनक रूप से धीमी ज़रूर है, लेकिन project जीवित है, और अगले साल इसकी रफ़्तार बढ़ सकती है
      https://blog.rust-lang.org/inside-rust/2023/11/15/spec-visio...
    • Mara की blog post, यानी पहला link, मूल रूप से इस पक्ष के क़रीब है कि Rust को standard की ज़रूरत नहीं क्योंकि उसके पास पहले से features जोड़ने और compatibility बनाए रखने के तरीके हैं
    • Ferrocene spec की वजह से Rust का इस्तेमाल ऐसे industries में भी किया जा सकता है
    • Go के पास सच में बहुत अच्छी spec और कई implementations हैं
      https://go.dev/ref/spec
    • इस दावे के जवाब में कि standard न होने पर कई organizations और industries इसे नहीं अपनाएँगी, एक प्रतिवाद यह है कि Rust उन organizations और industries के बिना भी अच्छा कर रहा है
      जो चीज़ अच्छी तरह काम कर रही है, उसे बदलने की ज़रूरत क्यों है, यह समझ नहीं आता

  • यह देखकर हैरानी होती है कि GCC-RS के प्रति इतनी नकारात्मक प्रतिक्रिया है
    अगर किसी भाषा की कई implementations न हों, तो वह काफ़ी कमजोर भाषा लगती है

    • पहले, खासकर C/C++ की वजह से, यह आम धारणा थी, लेकिन आजकल यह कहीं अधिक विवादास्पद है
      Rust community में सहमति अभी इस तरफ़ है कि मौजूदा तरीका — यानी परिभाषा के अनुसार एक standard compiler, बहुत सारे docs, safety-critical industries के लिए न्यूनतम spec, और कुछ module sub-areas की specs — कई implementations के ज़्यादातर फ़ायदे दे देता है और कमियाँ टाल देता है
    • लंबी अवधि में syntax stability और extensions/attributes के कारण feature bloat को रोकना समस्या है
      C में यह वास्तव में हो चुका है, और C++ तो बेहूदी और अजीब complexity की वजह से लगभग बचाव से बाहर है
      इसके बिना व्यावहारिक alternative implementations आना मुश्किल है
    • व्यक्तिगत रूप से मैं कई implementations की value समझता हूँ, लेकिन समस्या यह है कि इसे GCC के ऊपर बनाया जा रहा है
      GNU toolchain बिखरा हुआ है, और सच कहूँ तो समझ नहीं आता कि लोग उसके ऊपर development कैसे करते हैं
      यह कोई वैचारिक बात नहीं है; सचमुच समझ नहीं आता कि GCC खुद का development environment कैसे सेट किया जाता है
      बदकिस्मती से मुझे इसे कुछ बार bootstrap करना पड़ा है, और यह अब तक देखे गए software में सबसे खराब चलने वाली चीज़ों में से एक था

  • यह बात मज़ेदार लगी कि Sega Dreamcast homebrew community gccrs से नए games बना सकती है, और GCC plugin के ज़रिए unsafe Rust code का static analysis भी किया जा सकता है
    Dreamcast की Hitachi SH-4 architecture को rustc का LLVM backend support नहीं करता, लेकिन GCC करता है, इसलिए अधूरा gccrs भी ऐसे embedded use में काम आ सकता है

    • यह थोड़ा भ्रामक है
      इसके लिए GCC frontend की नहीं, सिर्फ़ GCC backend की ज़रूरत होती है

  • अब शायद उन architectures पर भी Rust support दिखेगा जिन्हें LLVM support नहीं करता लेकिन GCC करता है, जैसे Alpha, SuperH, VAX

    • इसमें mips64 भी शामिल है, जिसे rustc ने हाल में Loongson से funding/resources लाने में असफल रहने के बाद support से हटा दिया
      https://github.com/rust-lang/compiler-team/issues/648
      LLVM-शैली की सोच की सबसे बड़ी समस्या यह है कि architecture support को hardware companies से sponsorship, यानी paid developer positions निकलवाने के साधन की तरह इस्तेमाल किया जाता है
      GNU में changes merge करने की शर्तें परेशान करने वाली हद तक सख्त हो सकती हैं, लेकिन एक बार support अंदर आ जाए तो उसे लंबे समय तक maintain किया जाता है
      यह खरीदने और किराए पर लेने के फ़र्क जैसा है; GCC में support डालने में development time कहीं ज़्यादा लगता है, लेकिन एक बार आ गया तो बना रहता है
    • पहले से supported architectures में भी अतिरिक्त configuration options आ सकते हैं
      उदाहरण के लिए, हाल में पता चला कि RISC-V पर GCC RV32E target को support करता है, लेकिन LLVM नहीं
    • Rust से निकला PDP-11 machine code जल्दी देखना चाहूँगा
      आख़िरी बार देखा था तो GCC में standalone C compilation अभी भी काम कर रही थी

  • मेरे अनुभव में gccrs का “GNU Rust” जैसी अलग भाषा न बनाकर rustc के output, bugs और quirks तक को copy करने की कोशिश करना बड़ी गलती है
    Rust की कोई spec नहीं है; reference docs हैं, लेकिन उन्हें साफ़ तौर पर normative नहीं कहा गया है
    एकल reference implementation के अलावा दस्तावेज़ित न की गई भाषा लंबी अवधि में कमज़ोरी बनती है
    मौजूदा code को दोनों implementations पर चलाने लायक बनाए रखने का लक्ष्य समझदारी भरा है, लेकिन bug compatibility तक का वादा गलत फ़ैसला है, क्योंकि इससे खराब decisions और bugs fossilize हो जाते हैं
    Microsoft पुराने programs चलते रहने देते हुए security और reliability bugs ठीक करने में बहुत manpower लगाता है; Rust को अपने शुरुआती जीवन में ऐसा बोझ उठाने की ज़रूरत नहीं है
    अगर भाषा को evolve करना है, तो quality assurance और quality control स्वीकार करने होंगे
    quality को बाद में tests से inject नहीं किया जा सकता; architecture, design, और design/code review जैसी processes से इसे सही ढंग से काम करने लायक बनाना पड़ता है, और अगर fail भी हो तो सही दिशा में fail होना चाहिए
    Common Lisp, C++, FORTRAN जैसे मज़बूत standards ने इस विश्वास को अपनाया, और Python जैसी de facto standard के क़रीब कमजोर भाषाएँ लोकप्रिय तो हो सकती हैं, लेकिन बदलाव मुश्किल होता है — यह Python 2 से 3 के लंबे transition और कम implementations की संख्या से साफ़ दिखता है

    • अगर कोई बड़ा bug मिले, तो उसे upstream में report करके दोनों implementations में बदलाव किया जा सकता है

  • इस thread में देर से कह रहा हूँ, लेकिन यह ज़रूरी नहीं कि अच्छी बात ही हो
    distributions उन भाषाओं की रफ़्तार के साथ नहीं चल पातीं जिनके नए versions हर कुछ महीनों में आते हैं, इसलिए rustc या Go को distribution package के रूप में इस्तेमाल करना पहले से ही मुश्किल है
    अभी हैरानी की बात यह है कि कुछ systems GCC को गैर-ज़रूरी मानकर हटा देते हैं, और मौजूदा software updates के लिए सिर्फ़ upstream Go और Rust बनाए रखते हैं
    कुछ महीने पहले CVE की वजह से Go update करते समय यह देखकर बुरा हाल हो गया कि Go-based apps ने अपने-अपने Go environments चार अलग-अलग जगहों पर जमा कर रखे थे

  • Linux को चाहें तो पहले से Clang से compile करके पूरी LLVM-based toolchain इस्तेमाल की जा सकती है
    GNU “शुद्धता” के लिए इसे develop और maintain करने की यह duplicate effort उतनी क़ीमती नहीं लगती

    • यह शुद्धता का नहीं, choice का सवाल है
      ClangBuiltLinux community का तर्क था कि Linux को एक ही compiler पर निर्भर नहीं होना चाहिए, लेकिन Rust आने के बाद उन्हीं में से काफ़ी लोग अचानक मानने लगे कि single compiler भी ठीक है
    • यहाँ शायद गलतफ़हमी है
      मक़सद kernel को GNU-only से बाँधना नहीं, बल्कि pure GNU toolchain चुनने का विकल्प देना है