LLVM posta listesinde geliştirme konusunu sunan Google geliştiricilerinden biri çapraz platform standart C kitaplığı (Libc) LLVM projesi çerçevesinde.
Birkaç nedenden dolayı, Google mevcut libc'den memnun değil (glibc, müsl) ve şirket yeni bir uygulama geliştirme yolundaLLVM'nin bir parçası olarak geliştirmeyi planladığı. LLVM geliştirmeleri, son zamanlarda Google araçlarını oluşturmanın temeli olarak kullanılmıştır.
Gelişimin kademeli olması, kademeli olarak işlevselliğin artırılması planlanmaktadır. İlk seçeneklerin, uygulama ile libc sistemi arasında, gerçekleştirilmemiş özelliklerin ödünç alınacağı bir ara katman şeklini alması önerilmektedir.
Belirli bir işlevsellik düzeyine ulaştıktan sonra, yeni Libc, Libc sistemi için tam bir yedek olarak kullanılabilir.
X86-64 mimarisi, Linux ve statik bağlama desteği ile başlaması planlanmaktadır (dinamik yükleme, paketleme ve ek mimariler ikinci olarak uygulanacaktır).
Proje halen geliştirmenin ilk aşamasındadır, ancak temel hedefler zaten tanımlanmıştır:
- Parçalı bir kitaplık sağlama felsefesine uygun modülerlik ve geliştirmemonolitik bir topluluktan ziyade.
- PIE modlarında statik bağlantı desteği (konumdan bağımsız yürütülebilir dosyalar) ve PIE'siz. Statik olarak bağlantılı yürütülebilir dosyalar için CRT (C çalışma zamanı) ve PIE yükleyici sağlayın.
- C kütüphanesi işlevlerinin çoğunu destekler POSIX eklentileri ve mevcut uygulamalarda istenen bazı sisteme özgü uzantılar ile standart.
- Belirli uzantılara karşı dikkatli tutum sağlayıcıdan ve yalnızca gerektiğinde ekleyerek. Üçüncü taraf uzantı desteği için, Clang ve libc ++ proje yaklaşımının kullanılması önerilmektedir.
- LLVM Araçlarını Kullanarak Geliştirmede En İyi Uygulamaları Kullanmadezenfektanların uygulanması ve testlerin baştan kaldırılması gibi.
Aktif LLVM geliştiricilerinden biri şunu belirtti: LLVM araç setinin bir parçası olarak libc sunumu anlamsız değildir, ancak genellikle böyle bir ihtiyaçla musl kütüphanesini kullanırlar, İyi yazılmıştır, birden çok mimariyi destekler ve dinamik bağlantı dahil gerekli işlevselliği sağlar.
Musl'ın LLVM'ye dahil edilmesi ve ana proje ile senkronize bir çatal olarak geliştirilmesi gerekçelendirilebilir.
Fikri, Google'ın önerisinin ve Libc'nin LLVM sunumuna dahil edilmesinin neden çok kötü fikirler olduğunu tartışmaya çalışan Musl projesinin yazarı tarafından da dile getirildi:
Doğru, uyumlu ve yüksek kaliteli libc geliştirmek ve sürdürmek çok zor bir iştir. Sorun kod miktarında değil, doğru davranışı sağlamakta.
Ve C / C ++ ile yazılmış uygulamaların devasa deposu ve çalışma zamanı Libc tarafından kullanılan diğer dillerdeki uygulamalar göz önüne alındığında, arayüz uygulamasındaki zorluklar.
Nüansları hesaba katmadan alına yaklaşım, yalnızca mevcut birçok programın Libc ile çalışamayacağı gerçeğine yol açacaktır, ancak böyle bir proje tüketicilerin ilgisini çekmeyecektir.
Kurumsal gelişim Libc'i mahvedebilir, ancak yaygın kullanımı teşvik edin, bu da uygulamalarda uyumluluğu sağlamak için bilgisayar korsanları ekleme ihtiyacıyla sonuçlanacaktır.
Açık bir kurumsal projenin himayesi altındaki gelişme, toplumun çıkarlarına zarar verecek şekilde şirketin ihtiyaçlarına ve kararlarına yönelik kapsamı yönlendirecektir.
Örneğin, kendi başka bir programınızdaki bir hatanın neden olduğu bir sorunu tespit etmeniz durumunda, kontrol altındaki geliştirmede, Libc'nin bu hatayla uyumluluğunu garanti etmek, hatayı düzeltmekten daha kolaydır.
Apple, bu amaçlar için BSD libc çatalını kullanır ve Google, Fuchsia çatalını kullanır. Musl'ın geliştirici deneyimi, avukatların öncelikle lisans sorunlarını açıklığa kavuşturmak için kendisiyle iletişime geçtiğini gösteriyor.
kaynak: http://lists.llvm.org