Google'ın geliştiricilerinden biri LLVM projesinin bir parçası olarak çok platformlu bir standart C kütüphanesinin (Libc) geliştirilmesi hakkında LLVM posta listesinde. Google, çeşitli nedenlerden dolayı mevcut libc'den (glibc, musl) memnun değil ve şirket, LLVM'nin bir parçası olarak geliştirilmesi önerilen yeni bir uygulama geliştirme yolunda ilerliyor.
LLVM gelişmeleri yakın zamanda Google'ın montaj araçlarını oluşturmanın temeli olarak kullanıldı. Ana fikir şu; eğer Google zaten libc'sini geliştirmeye başladıysa, o zaman neden kendi sistemini C++ için kendi standart kütüphanesini (Libc++) sunan, ancak C için benzer bir standart kütüphaneye sahip olmayan LLVM'nin bir parçası olarak hemen geliştirmesin? (libc).
Geliştirmenin aşamalı olarak gerçekleştirilmesi ve işlevselliğin giderek artırılması planlanıyor. İlk seçeneklerin, uygulama ile Libc sistemi arasında, henüz uygulanmamış özelliklerin ödünç alınacağı bir katman olarak tasarlanması öneriliyor. Belirli bir işlevsellik düzeyine ulaştıktan sonra yeni Libc, Libc sisteminin tamamen yerine kullanılabilir. x86-64 mimarisi, Linux ve statik bağlantı desteğiyle başlamayı planlıyoruz (dinamik yükleme, bağlantı ve ek mimariler ikincil olarak uygulanacaktır).
Proje halen geliştirmenin ilk aşamasındadır, ancak temel hedefler zaten tanımlanmıştır:
- Monolitik bir set yerine ayrıntılı bir kütüphane sunma felsefesine uygun olarak modülerlik ve geliştirme;
- Modlarda statik bağlantı desteği (Konumdan bağımsız yürütülebilir dosyalar) ve PIE olmadan. Statik olarak bağlı yürütülebilir dosyalar için CRT (C çalışma zamanı) ve PIE yükleyicinin sağlanması;
- POSIX eklemeleri ve mevcut uygulamaların gerektirdiği bazı sisteme özgü uzantılarla birlikte standart C kitaplığı işlevlerinin çoğu için destek;
- Satıcıya özel uzantılara dikkat edin ve bunları yalnızca gerektiğinde ekleyin. Üçüncü taraf uzantıların desteğiyle ilgili olarak, Clang ve libc++ projelerinin yaklaşımının kullanılması önerilmektedir;
- LLVM araç setini kullanarak geliştirmede en başından itibaren sanitizer ve tüylenme testi kullanmak gibi en iyi uygulamaları kullanmak.
Aktif LLVM geliştiricilerinden biri Libc'yi LLVM araç setinin bir parçası olarak göndermenin mantıklı olduğu açıktır, ancak genellikle böyle bir ihtiyaç ortaya çıktığında, iyi yazılmış, çeşitli mimarileri destekleyen ve dinamik destek de dahil olmak üzere gerekli işlevselliği sağlayan musl kütüphanesini kullanırlar. bağlama. Musl'un LLVM'ye yerleştirilmesi ve ana projeyle senkronize bir çatal olarak geliştirilmesi haklı gösterilebilir.
Sizin de fikriniz Google'ın teklifinin ve Libc'nin LLVM dağıtımına dahil edilmesinin neden çok kötü fikirler olduğunu tartışmaya çalışan Musl projesinin yazarı:
- Doğru, uyumlu ve yüksek kaliteli bir Libc geliştirmek ve sürdürmek çok zor bir iştir. Sorun kodun miktarında değil, C/C++ ile şimdiye kadar yazılmış uygulamaların yanı sıra çalışma zamanı kullanılan diğer dillerdeki uygulamalar da dikkate alınarak doğru davranışın sağlanması ve arayüzlerin uygulanmasındaki zorluklardır. Libc tarafından. Nüansları dikkate almadan doğrudan bir yaklaşım, yalnızca mevcut birçok programın Libc ile çalışamayacağı, ancak o zaman böyle bir projenin tüketicilerin ilgisini çekmeyeceği gerçeğine yol açacaktır.
- Kurumsal gelişim, Libc'yi mahvedebilir, ancak yaygın kullanıma zorlayabilir, bu da uygulamalarda uyumluluğu sağlamak için hack'lerin eklenmesi ihtiyacını doğurur. Kurumsal bir açık kaynak projesinin himayesi altında yapılan geliştirme, topluluğun çıkarlarına zarar verecek şekilde, battaniyeyi şirketin ihtiyaçlarına ve çözümlerine doğru çekecektir. Örneğin, başka bir programdaki bir hatanın neden olduğu bir sorunu tanımlarsanız, kontrollü geliştirmede Libc'nin bu hatayla uyumlu olmasını sağlamak, hatanın kendisini düzeltmekten daha kolaydır. Apple bu amaçlar için BSD libc çatalını, Google ise Fuşya'daki musl çatalını kullanıyor. Musl geliştiricisinin deneyimi, lisanslama sorunlarını açıklığa kavuşturmak için esas olarak avukatlar tarafından kendisiyle temasa geçildiği, ancak şubelerinde işe yaramaz ve yıkıcı değişiklikler yapmadan önce teknik ayrıntıları açıklığa kavuşturmak için hiçbir zaman temasa geçilmediği yönündedir.
- Libc geliştirmede monokültürün bulunmaması ve tek kontrol yerine fikir birliğine dayalı standartlara odaklanma, uygulama geliştiricilerini belirli uygulamalara bağlı kalmak yerine standartları kullanmaya motive eder. Musl'un yazarının kütüphanesinin LLVM'ye dahil edilmesine karşı olmasının yanı sıra libc'nin LLVM içerisinde geliştirilmesine de karşı olmasının nedeni budur, çünkü bu durumda libc'nin bağımsız doğası kaybolur ve belirli bir uygulama birinci sınıf bir çözüm haline gelir. LLVM ve diğerleri ikinci sınıf bir çözüm haline geliyor.
Kaynak: opennet.ru