Zig Libc

 (ziglang.org)
2 puan yazan GN⁺ 2026-02-04 | 1 yorum | WhatsApp'ta paylaş
  • Zig dili, libc işlevlerini doğrudan Zig standart kütüphanesinde uygulama yönünde ilerliyor ve mevcut C kaynak kodunu kademeli olarak kaldırıyor
  • Şu ana kadar yaklaşık 250 C kaynak dosyası silindi ve 2032 dosya kaldı
  • Bu geçiş; derleme hızında artış, kurulum boyutunda azalma ve statik bağlama sırasında ikili dosya boyutunda küçülme gibi etkiler sağlıyor
  • Son iyileştirmelerle birlikte zig libc, ayrı bir statik arşiv yerine Zig Compilation Unit (ZCU) içinde diğer kodlarla birlikte optimize ediliyor; böylece yinelenen kod kaldırma ve LTO düzeyinde optimizasyon mümkün oluyor
  • Zig, kendi statik libc sağlayıcısına dönüşürken, ilgili sorunlar oluştuğunda hata raporlarının doğrudan Zig projesine gönderilmesi gerekiyor

Zig libc projesine genel bakış

  • Birden fazla katkıcı, zig libc alt projesine katılarak mevcut C tabanlı libc uygulamasını Zig standart kütüphanesi sarmalayıcılarıyla değiştiriyor
    • Amaç, yinelenen C kodunu kaldırmak ve memcpy, atan2 gibi basit eşleme işlevlerini ya da strnlen gibi genel işlevleri sarmalayıcı biçiminde sunmak
    • Örneğin strnlen işlevi, Zig'in std.mem.findScalar fonksiyonu kullanılarak uygulanıyor
  • Şu ana kadar yaklaşık 250 C kaynak dosyası silindi, 2032 dosya kaldı

Performans ve yapısal iyileştirmeler

  • Her işlev Zig'e taşındıkça harici proje ve C dili bağımlılıkları azalıyor
    • Bunun sonucu olarak derleme hızı artıyor, kurulum boyutu sadeleşip küçülüyor ve statik bağlı kullanıcı uygulamalarının ikili dosya boyutu azalıyor
  • Yakın tarihli değişikliklerle zig libc, Zig Compilation Unit (ZCU) içinde diğer Zig kodlarıyla birlikte derleniyor
    • Ayrı bir statik arşive bağlanmak yerine derleyici ve bağlayıcının birleşik yapısından yararlanılıyor
    • Bu sayede yinelenen kod kaldırma ve işlevler arası optimizasyon mümkün oluyor
    • Bu yaklaşım link time optimization (LTO) ile benzerlik taşısa da, bağlayıcı aşamasında değil frontend aşamasında gerçekleştiriliyor

Gelecekte genişleme olasılığı

  • Son dönemdeki std.Io değişiklikleriyle birleştirildiğinde, libc'nin I/O davranışının kullanıcı tarafından denetlenebilmesi mümkün olabilir
    • Örnek: read, write çağrılarını io_uring olay döngüsüne entegre etmek
    • Kaynak sızıntısı tespiti özelliğini üçüncü taraf C kodlarına da uygulamak mümkün olabilir
    • Ancak bunlar şu anda yalnızca denenmemiş fikirler aşamasında

Test ve kalite güvencesi

  • Szabolcs Nagy'nin libc-test projesi, matematik işlevlerinde gerilemelerin önlenmesine büyük katkı sağlıyor
    • Bu test seti, Zig libc'nin doğruluğunu doğrulamak için kullanılıyor

Kullanıcılar için not

  • Zig, musl, mingw-w64, wasi-libc işlevlerini kendisinin sağladığı bir aşamaya geçiyor
    • İlgili sorunlar ortaya çıktığında hata raporlarının doğrudan Zig projesine gönderilmesi gerekiyor
    • Bunun amacı, bağımsız libc projelerinin bakımcılarına yanlışlıkla konu açılmasını önlemek

Kapanış

  • Yazının son cümlesi “Abolish ICE” ifadesiyle bitiyor (ek açıklama yok)

İlgili okumalar

1 yorum

 
GN⁺ 2026-02-04
Hacker News görüşleri

  • 250 C dosyası silindi ve şimdi 2032 tane kaldı
    Zig'in libc'yi içeriden dışarıya doğru ikame etme sürecini izlemek, uzun vadede oldukça heyecan verici bir proje

    • Zig'de her zaman hayran olduğum şeylerden biri bu oldu
      Birçok dil C'nin yerini alacağını iddia ediyor, ama C ABI ve build sistemini doğal biçimde entegre eden neredeyse tek dil Zig oldu
      translate-c özelliği de şaşırtıcı derecede iyi çalışıyor
      C++ gibi %99 uyumluluğu korumaya çalışmak yerine, C'nin sadeliğini koruyup dilin tuzaklarından kaçınma tercihini daha akıllıca buluyorum

  • Bunun uzun vadede Zig'in OpenBSD üzerinde çalışmayacağı anlamına gelip gelmediğini merak ediyorum
    OpenBSD doğrudan syscall kullanımını engelleyip yalnızca libc üzerinden çağrı yapılmasını zorunlu kılıyor
    İlgili olarak şu başlığa bakılabilir

    • Bu yalnızca static libc için geçerli
      -dynamic -lc seçeneğini verirseniz hedef sistemin libc fonksiyonları sağlanır
      macOS gibi yalnızca dinamik libc destekleyen sistemler de var ve bildiğim kadarıyla OpenBSD statik libc'yi de destekliyor
    • İlgili yanıta buradan bakabilirsiniz

  • Zig projesinin C kütüphanelerini linkleme biçimi açısından bu çok ilginç bir değişiklik
    Ama MinGW kullanan Windows için C programlarını Zig ile çapraz derlerken, hâlâ MinGW'nin libc'sini statik olarak linkleyip linkleyemeyeceğini merak ediyorum

    • Bu durumda bir değişiklik yok
      -target x86_64-windows-gnu -lc belirtirseniz bazı libc fonksiyonlarını Zig, bazılarını ise vendored mingw-w64 sağlar
      Ayrı bir mingw-w64 kurulumu olmadan Zig her şeyi sağlar
      İsterseniz --libc libc.txt ile harici bir libc'yi doğrudan da belirtebilirsiniz

  • Harika bir fikir ama port edilmiş kod için glibc veya musl'daki CVE açıklarını takip etmeye devam etmek gerekip gerekmediği konusunda endişeliyim

    • Zaten standart kütüphanede de aynı şey yapılıyor
      Matematik gibi paylaşılan kod yollarında ise potansiyel hatalar hatta azalıyor

  • “libc sınırının ötesinde LTO'yu etkinleştirmeye benziyor ama bu, linker yerine frontend'de düzgün şekilde yapılıyor” şeklinde bir açıklama vardı
    Bunun neden linker aşamasında çok geç kaldığını, Zig'in LLVM IR düzeyindeki bir linker'dan daha fazla optimizasyon yapıp yapamayacağını merak ediyorum

    • Frontend tarafında inline etme ve dead code elimination mümkün
      Çünkü optimize edilmiş statik kütüphanelerde link zamanı bu tür optimizasyonları yapmak zor oluyor

  • Son std.Io değişiklikleriyle birleşince, libc'nin I/O davranışını kullanıcının doğrudan kontrol edebilmesi ilginç
    Örneğin tüm read/write çağrılarını io_uring event loop içine dahil etmek gibi
    Ben şahsen kqueue tarafıyla daha çok ilgileniyorum ama bu alıntının orası için de geçerli olduğunu düşünüyorum

  • libc içinde korkutucu pek çok kısım var ama bu gerçekten ilginç bir proje

    • Elbette faydalı fonksiyonlar da var
      Mesela "memfrob" ya da "strfry" gibi şeyler; tabii şaka bir yana, bunlar sadece glibc'de var :)

  • Rust'ta da böyle bir şey olup olmadığını merak ediyorum
    Zig vs Rust tartışması çıkarmaya çalışmıyorum, sadece Rust projelerinde de daha bağımsız bir ortam kurmak istiyorum

    • Rust için de birkaç libc implementasyonu var
      • c-ward: Rust ile yazılmış bir libc implementasyonu
      • relibc: Redox OS için ama Linux'ta da çalışıyor
      • rustix: C kullanmadan POSIX API'lerine güvenli bağlamalar sağlar

  • Zig'in 1.0 sürümüne ne zaman ulaşacağını bilen var mı diye merak ediyorum
    Dille çok ilgileniyorum ama hâlâ çok değiştiği için önemli projelerde kullanmakta tereddüt ediyorum

    • Kimse tam olarak bilmiyor
      Yine de Bun, Ghostty, Tigerbeetle gibi büyük production projeleri bunu gayet iyi takip ediyor
      Zig'in semantiği basit olduğu için, sürüm yükseltirken çoğunlukla sadece derleyiciyi güncellemek ve birkaç mekanik düzeltme yapmak yetiyor
      Beni durduran tek şey ekip arkadaşlarımın bunu benimsemeye ne kadar istekli olduğu; bu yüzden şimdilik tek başıma yapabileceğim projelerle ilerliyorum
    • Resmî bir 1.0 takvimi yok
      Bu arada şu video ilginizi çekebilir)