GCC tabanlı Rust derleyicisi geliştirmesinde ilerleme

 (lwn.net)
2 puan yazan GN⁺ 2023-12-19 | 1 yorum | WhatsApp'ta paylaş
  • gccrs, GCC içinde bir Rust derleyicisi gerçekleştirmeyi amaçlayan ve 2014’te başlayan bir proje; tamamlanmasına hâlâ çok olsa da standart kütüphaneyi derleme ve GCC 14’e dahil olma yönünde ilerleme kaydediyor
  • Proje, hızla değişen en güncel Rust yerine Rust 1.49’u hedef aldı; ancak standart kütüphane içindeki bağımlılıklar nedeniyle const generics gibi özellikleri sonunda yine de gerçekleştirmek zorunda kaldı
  • core ve alloc derlemesi; makro ad çözümleme, dekoratör makroları, GCC’de bulunmayan LLVM compiler intrinsic’leri ve borrow checker eksikliği nedeniyle hâlâ tıkanmış durumda
  • rustc_codegen_gcc, rustc’nin bir kısmını kullanıp arka uç kod üretimi için GCC’den yararlanan daha olgun bir yaklaşım ve Ekim 2023 itibarıyla ek yama olmadan Rust for Linux’u derleyebiliyor
  • gccrs için GCC güvenlik eklentileri, statik analiz, LLVM’in desteklemediği mimariler ve Rust for Linux gibi net motivasyonlar var; ancak pratik kullanım açısından hâlâ rustc_codegen_gcc kadar geniş değil

gccrs’nin hedefi ve mevcut durumu

  • gccrs, GNU Compiler Collection(GCC) içinde bir Rust derleyicisi gerçekleştirmeyi amaçlayan bir projedir
  • 2014’te başladı ve LWN’nin daha önceki kapsamına alınmasından sonra, proje raporuna göre ilerleme kaydedildi
  • 2022’de hedef GCC 13’e dahil olmaktı, ancak bu başarılamadı; Kasım 2023 aylık raporu itibarıyla hedef GCC 14’e dahil olmak
    • GCC 14, 2024 ortasında çıkması muhtemel bir sürüm olarak ele alınıyor
  • Ekim 2023’teki EuroRust 2023’te Arthur Cohen, “The road to compiling the standard library with gccrs” başlıklı sunumunda Rust standart kütüphanesini derleme çalışmasını ve neden hâlâ derlenemediğini anlattı

Neden Rust 1.49 hedeflendi?

  • gccrs, Rust’ın en yeni sürümünü sürekli takip etmek yerine Rust 1.49’u hedefliyor
  • Rust 1.49, 2020 sonlarında yayımlandı ve Rust 1.50’de genel kullanıma açılan const generics desteğinden önceki son sürümdü
  • Proje const generics’ten kaçınmak istedi, ancak bunun Rust 1.49’un standart kütüphanesinin içinde zaten kullanılıyor olması nedeniyle sonunda bunu görmezden gelmek mümkün olmadı
  • const generics daha sonra tamamen gerçekleştirildi ve artık bir engel değil
  • gccrs, Rust’ın bir üst kümesini ya da ayrı bir “GNU Rust” dili oluşturmak istemiyor
    • Hedef, rustc çıktısını, hatalarını ve alışılmadık davranışlarını bile yeniden üretmek
    • Bunun için hem Rust test paketi hem de GCC test paketi kullanılıyor

Standart kütüphane derlemesinde tıkanan noktalar

  • Rust standart kütüphanesi birden fazla crate’ten oluşur
  • gccrs, en önemli iki crate olan core ve alloc için derleme desteği üzerinde çalışıyor
    • core, ilkel tipler ve makrolar gibi standart kütüphanenin temel özelliklerini gerçekleştirir
    • alloc, heap bellek ayırma ve çeşitli kapsayıcı tipleri ele alır
  • Şu anda gccrs, aşağıdaki eksikler nedeniyle bu crate’leri derleyemiyor
    • Makro ad çözümleme davranışı doğru değil
    • Dekoratör makro desteği tam değil
    • Borrow checker olmadığı için kod güvenliği düzgün biçimde denetlenemiyor
    • GCC’de bulunmayan LLVM compiler intrinsic’lerinin gerçekleştirilmesi gerekiyor
  • Borrow checker eksikliği derlemenin kendisini engellemese de Rust kodunun güvenlik denetimlerinin düzgün yapılmasını engelliyor

Prosedürel makrolar ve GCC entegrasyon çalışmaları

  • Eylül 2023’te GNU Tools Cauldron’da Pierre-Emmanuel Patry, GCC 14’e dahil edilme süreci ve makro çalışmalarına odaklanan bir sunum yaptı
  • Prosedürel makro (procedural macro) gerçekleştirme yöntemi, GCC derleme sisteminde değişiklik gerektiriyor
  • Prosedürel makrolar, C veya C++ makroları gibi yalnızca kaynak metin üretmeyip token stream üreten işlevsel makrolardır
  • Rust’ta bunlar yerleşik proc_macro crate’iyle gerçekleştirilir
  • Prosedürel makroların uygulanması zordur, ancak güçlü özellikler sağlar
    • #[attribute] dekoratörleri
    • #[derive()] dekoratörleri
    • Derleme zamanı değerlendirmeye dayalı alan özel dilleri üretme
  • GNU Cauldron sunumu sırasında gccrs’nin GCC’ye upstream edilmesi gereken 800’den fazla commit’i vardı

GCC ekosistemini Rust için kullanmak istemelerinin nedeni

  • gccrs’nin başlıca motivasyonlarından biri, GCC’nin güvenlik eklentilerini Rust kodu için de kullanabilmek
  • GCC’de hata ayıklama, statik analiz ve hardening’e yardımcı olan çok sayıda eklenti bulunur ve bunlar GCC ara gösterimi üzerinde çalışır
  • gccrs, Rust geliştiricilerinin mevcut GCC eklentilerini yeniden kullanabildiği bir iş akışını desteklemek istiyor
  • Cohen, C programcılarının dosya tanımlayıcılarını kapatmayı unutma hatasını uzun süredir yaptığı için bunu yakalayan çok sayıda eklenti bulunduğunu örnek verdi
  • Amaç, Rust’taki unsafe kodda hataları yakalamak için mevcut GCC eklentileri ve statik analiz araçlarının kullanılabilmesini sağlamak

Halihazırda kısmen kullanıldığı alanlar

  • Cohen’e göre Sega Dreamcast homebrew topluluğu, Dreamcast oyun konsolu için yeni oyunlar oluşturmakta gccrs kullanıyor
  • Dreamcast topluluğunun ilgisinin nedeni, rustcnin LLVM arka ucunun konsolun Hitachi SH-4 mimarisini desteklememesi, buna karşılık GCC’nin desteklemesi
  • gccrs henüz tamamlanmamış olsa da bu tür gömülü kullanım senaryolarında yararlı
  • GCC eklentileri kullanılarak unsafe Rust kodunun statik analizi de şimdiden mümkün
  • gccrs üzerinde çalışılırken Deref ve makro ad çözümleme gibi belirtimi yeterince net olmayan dil özellikleri ortaya çıktı ve proje, Rust belirtimine katkı da sağlayabildi
    • Rust’ın şu anda resmî bir belirtimi yok, ancak RFC 3355 doğrultusunda belirtim çalışmaları sürüyor

Hâlâ geliştirilmekte olan temel özellikler

  • gccrs’de Rust derleyicisinin birçok temel özelliği hâlâ eksik
  • Başlıca gerçekleştirilmemiş veya geliştirilmekte olan özellikler şunlar
    • async/await
    • GCC’de bulunmayan LLVM intrinsic’leri
    • println!() gibi çıktı makrolarının kullandığı format_args!() makrosu
    • Rust referans kurallarını zorunlu kılan borrow checker
  • Borrow checker için en güçlü çözüm adayı, ayrı bir proje olan Polonius
  • Cohen, gccrs’nin birkaç ay içinde Polonius’u entegre etme ihtimalinin yüksek olduğunu söyledi
  • Jakub Dupak son birkaç ayda bu çalışma kapsamında ilerleme sağladı
  • Polonius, şu anda rustcnin borrow checker’ı ile anlamsal olarak eşdeğer bir borrow checker gerçekleştiren bir kütüphane
    • Referans yaşam süresini hesaplamak için farklı bir algoritma kullanır
    • Uzun vadede rustcnin mevcut borrow checker’ındaki eksikleri ve köşe durumları çözmeyi hedefler
    • Yeterince olgunlaşırsa gelecekte rustc de Polonius’u benimseyebilir

format_args!() neden gerekli?

  • Kasım 2023 gccrs aylık raporuna göre format_args!() makrosu üzerinde çalışmaya başlandı
  • format_args!(), string biçimlendirme makrolarına aktarılacak argümanları oluşturan yardımcı bir makrodur
  • Bu özellik Display ve Debug trait’leriyle ilişkilidir
  • format!() ve println!() gibi makrolara verilecek argümanları hazırlamak için gereklidir
  • format_args!() olmadan Rust programları biçimlendirilmiş çıktı üretemez
  • Bu nedenle, gccrs’nin bir “Hello, World” programını derleyebilmesinden önce bile gerekli bir özelliktir
  • format_args!() hakkında derinlemesine açıklama için Mara Bos’un blog yazısı da ele alınıyor

rustc_codegen_gcc ile farkı

  • rustc_codegen_gcc, gccrs’den farklı bir GCC tabanlı Rust projesidir
  • gccrs’den daha olgundur, ancak kapsamı daha sınırlıdır
  • Rust derleyicisini sıfırdan tamamen gerçekleştiren bir yaklaşım değildir
  • rustcnin LLVM arka uç API’sine bağlanmak için libgccjit kütüphanesini kullanır
  • Derlemenin büyük bölümünü rustc yapar, daha sonraki aşamada ise GCC kullanılır
  • libgccjit adında JIT geçse de rustc_codegen_gcc, ahead-of-time derlemeyi amaçlar
  • Başlıca hedef, LLVM’in desteklemediği platformlarda Rust kod üretimini mümkün kılmaktır
  • Ekim 2023 itibarıyla rustc_codegen_gcc, ek yama olmadan Rust for Linux’u derleyebiliyor
  • Geçen yıl içinde SIMD ve link-time optimization desteği eklendi
    • Bu iki özellik daha önce test başarısızlıklarının nedeni olarak gösteriliyordu
  • Cohen, EuroRust sunumunda birkaç kez şimdilik gccrs yerine rustc_codegen_gcc kullanılmasını tavsiye etti
  • rustc_codegen_gcc zaten upstream Rust deposuna dahil edilmiş durumda

Rust for Linux ve sürüm farkı

  • Rust for Linux, Linux çekirdeğine Rust desteği eklemeyi amaçlayan bir girişimdir
  • Cohen, Linux çekirdeğini gccrs projesinin temel motivasyonlarından biri olarak gösterdi
    • Çünkü çekirdekle ilgili birçok kişi çekirdeğin yalnızca GNU araç zinciriyle derlenmesini tercih ediyor
  • Şu anda Rust for Linux projesi, çekirdekteki Rust kodunu derleme yöntemi olarak rustc veya rustc_codegen_gcc seçeneklerini belgeliyor
  • Çekirdekte çeşitli derleme araçları için desteklenen en düşük sürümler de belgelenmiş durumda
    • rustc, en düşük sürüm olarak değil tam olarak eşleşmesi gereken bir sürüm olarak ele alınıyor
    • Şu anda desteklenen rustc sürümü, Ekim 2023’te yayımlanan 1.73.0
  • gccrs’nin hedeflediği Rust 1.49 ile Rust for Linux’un gerektirdiği Rust 1.73.0 arasında büyük bir fark var
  • Rust for Linux desteği gccrs’nin açık hedeflerinden biri olsa da bu sürüm farkı nedeniyle hâlâ oldukça uzak

Genel değerlendirme

  • gccrs deposunda 1 Ocak 2023’ten bu yana 3.000’den fazla commit bulunuyor
  • Son bir yılda proje kayda değer ilerleme gösterdi
  • Ancak sıfırdan tam bir Rust derleyicisi gerçekleştirme kapsamı çok büyük olduğundan, neredeyse tüm pratik amaçlar için hâlâ kullanılabilir durumda değil
  • rustc_codegen_gcc, upstream Rust deposuna birleştirildi ve Rust for Linux’ta gerçek kullanımda bulunuyor
  • Rust dili için birden fazla bağımsız derleyici gerçekleştirmesinin olduğu aşamaya henüz gelinmedi, ancak o yöne doğru yaklaşılıyor

İlgili okumalar

1 yorum

 
GN⁺ 2023-12-19
Hacker News yorumları

  • Yalnızca yazının iddiasına bakınca gccrs’nin motivasyonu biraz zayıf görünüyor
    GCC güvenlik eklentileri ya da Linux çekirdeği tarafında GNU araç zinciri tercihi, neden GCC’yi backend olarak kullanmak isteyebileceğinizi açıklar; ancak neden yinelenen bir frontend gerektiğini açıklamaz
    Rust’ın, C++’ta olduğu gibi farklı derleyici anahtarları, dil desteği düzeyi farkları ve platforma özgü hatalar yüzünden çapraz platform geliştirmenin zorlaşması hatasını tekrarlamamasını umuyorum
    Bu yüzden gccrs’nin rustc_codegen_gcc’ye göre neden daha iyi bir yaklaşım olduğunu açıklamaları iyi olurdu; ikincisi çok daha az çaba ve riskle aynı hedefe ulaşabiliyor gibi görünüyor

    • Bir Rust uygulamasının daha olması, Rust belirtimini doğrulayan ve tanımsız davranışı azaltan bir denetim mekanizması işlevi görebilir
      MSVC’de bir derleyici hatasıyla karşılaşırsanız bunu bildirip GCC’ye geçerek çalışmaya devam edebilirsiniz, ama Rust’ta şu an böyle bir seçenek yok
    • Rust zaten C++’ın hatalarından ders çıkarıyor
      Alıntıda dendiği gibi, Rust’ın üst kümesi olmamaya yönelik dikkat bunun bir örneği
      C/C++’ın sorunu, derleyici üreticilerinin birbirleriyle “daha iyi” olmak için rekabet etmesiyle ortaya çıktı ve birden fazla frontend genelde çok sayıda hata ile yanlış uygulamayı açığa çıkarma avantajına sahip
    • Bu sorunun neden sürekli gündeme geldiğini anlamıyorum
      Rust sanki kutsalmış da frontend’in yeniden yazılması yasakmış gibi değil ve Rust’ı yeni mimarilerde bootstrap etmek hâlâ sancılı
      LLVM’nin desteklemediği mimariler için çalışan bir Rust derleyicisi de yok
      codegen_rust_gcc de mevcut Rust derleyicisiyle aynı bootstrap sorununa sahip ve Rust’ın çeşitli bölümlerine mimari desteği eklemek gerekiyor; Rust bakımcıları da buna pek istekli değildi
      Bu yüzden yakın gelecekte hemen kullanılabilir bir Rust derleyicisinin çıkması ve Alpha gibi mimarilerde de Rust’laştırılmış kütüphanelerin büyük acılar yaşamadan yeniden derlenebilmesi beni çok memnun eder
    • Bu mantıkla, LLVM topluluğunun neden DragonEgg kullanmaya devam etmek yerine Clang, Clang++ ve libc++ geliştirdiğini de sormak gerekir
      Zaten GCC, G++, libstdc++ ve EDG C++ frontend’i vardı
      GCC, Clang, MSVC ve diğer derleyiciler birbirini tamamlar, farklı amaçlara ve pazarlara hizmet eder ve dilin tek bir uygulamanın tesadüfi özelliklerine değil, belirtime uygun biçimde sağlamlaşmasına yardımcı olur
      GNU Toolchain Project, LLVM Project ve Rust projesinin hepsi sorunlar yaşadı; bu yüzden tek hata noktasına bağımlı olmamak daha iyidir ve yedeklilik ile kırılganlık karşıtlığı dosttur
    • Rust’ın C++ ve C’nin hatalarından öğrenmesi gerektiği söylenirken, bunun tarihin en uzun ömürlü, en etkili ve en yaygın dağıtılmış dillerinin hatalarından öğrenmek anlamına geldiğini düşünüyorum
      Dil standardına kötü gözle bakıp “bu kod C99/C++11’dir” demek yerine “bu kod SHA256 karması e49d560cd008344edf745b8052ef714b07595808898c835f17f962a10012f964 olan rustc ikilisi/kaynağında çalışır” demeyi tercih etmek kafa karıştırıcı

  • Rust’ın bir dil standardına ihtiyacı var
    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ı ortaya çıkana kadar Rust’ı benimsemeyecek çok sayıda kurum ve sektör var
    C, C++, C#, hatta JavaScript’in (ECMAScript) bile bir dil standardı varken Rust’ın olmaması için bir neden yok
    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...

    • O RFC zaten kabul edildi ve fiilen ilerlemeye başladı
      İlerleme hayal kırıklığı yaratacak kadar yavaş olsa da proje canlı ve gelecek yıl ivme kazanma ihtimali var
      https://blog.rust-lang.org/inside-rust/2023/11/15/spec-visio...
    • Mara’nın blog yazısı, yani ilk bağlantı, Rust’ın zaten özellik ekleme ve uyumluluğu koruma araçlarına sahip olması nedeniyle özünde standarda ihtiyaç duymadığı görüşüne daha yakın
    • Ferrocene belirtimi sayesinde bu tür sektörlerde de Rust kullanılabilir
    • Go’nun gerçekten iyi bir belirtimi ve birden fazla uygulaması var
      https://go.dev/ref/spec
    • Standart olmazsa benimsemeyecek çok sayıda kurum ve sektör olduğu iddiasına karşı çıkan görüş ise Rust’ın bu kurumlar ve sektörler olmadan da gayet iyi durumda olduğu yönünde
      Zaten iyi çalışan bir şeyi neden değiştirmemiz gerektiğini anlamıyorum

  • GCC-RS’e bu kadar olumsuz tepki verilmesi şaşırtıcı
    Bir dilin birden fazla uygulaması yoksa, bana göre oldukça zayıf bir dildir

    • Eskiden, özellikle C/C++ yüzünden bu yaygın bir kabuldü ama bugünlerde çok daha tartışmalı
      Rust topluluğundaki uzlaşı, mevcut yaklaşımın; yani tanım gereği standart olan tek bir derleyici, bol miktarda dokümantasyon, güvenlik açısından kritik endüstriler için asgari bir spesifikasyon ve bazı modül alt alanı spesifikasyonlarının, birden fazla uygulamanın avantajlarının çoğunu getirirken dezavantajlarından kaçındığı yönünde
    • Uzun vadede sorun söz dizimi kararlılığı ve uzantılar/öznitelikler nedeniyle özelliklerin şişmesini engellemek
      Bu C’de fiilen yaşanıyor ve C++ zaten saçma ve tuhaf bir karmaşıklık yüzünden neredeyse kurtarılamaz durumda
      Bu olmadan gerçekçi alternatif uygulamaların ortaya çıkması zor
    • Kişisel olarak birden fazla uygulamanın değerini anlıyorum ama sorun bunun GCC üzerine kuruluyor olması
      GNU araç zinciri darmadağınık ve insanların gerçekten bunun üzerinde nasıl geliştirme yaptığını bilmiyorum
      Bu ideolojik bir mesele değil; düpedüz GCC’nin kendi geliştirme ortamının nasıl kurulduğunu anlayamıyorum
      Birkaç kez bootstrap etmeye çalışacak kadar şanssız oldum ve şimdiye kadar gördüğüm yazılımlar içinde en kötü çalışan şeylerden biriydi

  • Sega Dreamcast homebrew topluluğunun gccrs ile yeni oyunlar yapabilmesi ve GCC eklentileriyle unsafe Rust kodu için statik analiz yapılabilmesi hoşuma gitti
    Dreamcast’in Hitachi SH-4 mimarisi, rustcnin LLVM backend’i tarafından desteklenmiyor ama GCC tarafından destekleniyor; bu yüzden tamamlanmamış durumdaki gccrs bile bu tür gömülü kullanım senaryolarında faydalı olabilir

    • Bu biraz yanıltıcı
      Bunun için gereken şey bir GCC frontend’i değil, yalnızca GCC backend’i

  • Artık LLVM’in desteklemediği ama GCC’nin desteklediği Alpha, SuperH, VAX gibi mimarilerde de Rust desteği görebiliriz

    • Yakın zamanda Loongson’dan fon/kaynak desteği almaya çalışıp başarısız olduktan sonra rustcnin desteği bıraktığı mips64 de buna dahil
      https://github.com/rust-lang/compiler-team/issues/648
      LLVM tarzı düşüncenin en büyük sorunu, mimari desteğini donanım şirketlerinden destek, yani maaşlı geliştirici pozisyonları koparmak için bir araç olarak kullanması
      GNU tarafında değişikliklerin birleştirilme ölçütleri sinir bozacak kadar yüksek olabilir ama bir kez kabul edilip desteklenmeye başlandı mı uzun vadede korunuyor
      Bu, satın almakla kiralamak arasındaki fark gibi; GCC’ye destek eklemek için çok daha fazla geliştirme zamanı gerekiyor ama bir kez girdikten sonra kalıyor
    • Hâlihazırda desteklenen mimariler için de ek yapılandırma seçenekleri gelebilir gibi görünüyor
      Örneğin yakın zamanda RISC-V tarafında GCC’nin RV32E hedefini desteklediğini, LLVM’in ise desteklemediğini öğrendim
    • Rust’tan çıkan PDP-11 makine kodunu bir an önce görmek istiyorum
      En son kontrol ettiğimde GCC’de bağımsız C derlemesi hâlâ çalışıyordu

  • Deneyimlerime göre gccrs’nin “GNU Rust” diye özel bir dil yaratmak yerine rustcnin çıktısını, hatalarını ve tuhaflıklarını bile birebir kopyalamaya çalışması büyük bir hata
    Rust’ın bir spesifikasyonu yok; başvuru dokümanları var ama açıkça normatif değiller
    Tek bir referans uygulama dışında belgelenmemiş bir dil, uzun vadede zayıf kalır
    Mevcut kodun iki uygulamada da çalışmasını garanti etmeye çalışmak makul bir hedef ama hata uyumluluğunu da vaat etmek, kötü kararları ve hataları fosilleştirmek olur
    Microsoft, eski programların çalışmaya devam etmesini sağlarken güvenlik ve güvenilirlik hatalarını düzeltmek için büyük insan gücü harcıyor; Rust’ın ömrünün bu kadar erken safhasında böyle bir yük üstlenmesine gerek yok
    Dili evrimleştirmek istiyorsanız kalite güvencesini ve kalite kontrolünü kabul etmeniz gerekir
    Kaliteyi sonradan testlerle enjekte edemezsiniz; mimari, tasarım ve tasarım/kod incelemeleri gibi süreçlerle sistemin doğru çalışmasını ve başarısız olduğunda bile doğru yönde başarısız olmasını sağlamanız gerekir
    Common Lisp, C++, FORTRAN gibi güçlü standartlar bu anlayışı benimsedi; Python gibi fiilen standart sayılabilecek daha zayıf diller de popüler olabilir ama değişimin zor olması, Python 2’den 3’e uzun geçişte ve az sayıdaki uygulamada açıkça görüldü

    • Büyük bir hata bulunursa upstream’e bildirilip iki uygulama da değiştirilebilir gibi görünüyor

  • Bu başlığa geç katılıyorum ama bunun mutlaka iyi bir şey olmayabileceğini düşünüyorum
    Dağıtımlar, birkaç ayda bir yeni sürüm çıkaran dilleri yakalayamıyor; bu yüzden rustc veya Go’yu dağıtım paketi olarak kullanmak zaten zor
    Şu anda şaşırtıcı biçimde GCC’nin artık gereksiz görülüp kaldırıldığı, yalnızca mevcut yazılımları güncel tutmak için upstream Go ve Rust’ın korunduğu sistemler var
    Birkaç ay önce bir CVE nedeniyle Go’yu güncellediğimde, Go tabanlı uygulamaların kendi Go ortamlarını dört ayrı yerde sakladığını görmek tam bir kabustu

  • Linux zaten istenirse Clang ile derlenip tamamen LLVM tabanlı bir araç zinciri kullanılabiliyor
    GNU “saflığı” uğruna bunu geliştirmek ve sürdürmek için harcanan mükerrer çaba buna değiyor gibi görünmüyor

    • Mesele saflık değil, seçenek meselesi
      ClangBuiltLinux topluluğu, Linux’un tek bir derleyiciye bağımlı olmaması gerektiğini savunuyordu ama Rust geldikten sonra aynı kişilerden epeyce bir kısmı birdenbire tek derleyicinin de sorun olmadığını düşünmeye başladı
    • Burada bir yanlış anlama var gibi
      Amaç çekirdeği yalnızca GNU’ya bağlamak değil, sadece tamamen GNU araç zinciri seçeneğini mümkün kılmak