Jeden z programistów Google przedstawił na liście mailingowej LLVM temat tworzenia wieloplatformowa standardowa biblioteka C. (Libc) w ramach projektu LLVM.
Z kilku powodów, Google nie jest zadowolony z aktualnej biblioteki libc (glibc, muzl) a firma jest na dobrej drodze do opracowania nowej implementacji, którą zamierza rozwijać w ramach LLVM. Rozwój LLVM został ostatnio wykorzystany jako podstawa do tworzenia narzędzi Google.
Rozwój planowany jest sukcesywnie, stopniowo zwiększając funkcjonalność. Proponuje się, aby pierwsze opcje miały postać warstwy pośredniej między aplikacją a systemem libc, z której będą pożyczane niezrealizowane funkcje.
Po osiągnięciu określonego poziomu funkcjonalności, nowy Libc może być używany jako kompletny zamiennik dla systemu Libc.
Planuje się rozpocząć od obsługi architektury x86-64, Linuksa i statycznego wiązania (dynamiczne ładowanie, pakowanie i dodatkowe architektury zostaną zaimplementowane jako drugie).
Projekt wciąż znajduje się w początkowej fazie realizacji, ale podstawowe cele zostały już zdefiniowane:
- Modułowość i rozwój zgodnie z filozofią dostarczania biblioteki ziarnistej, a nie monolityczny zespół.
- Obsługa łącza statycznego w trybach PIE (pliki wykonywalne niezależne od pozycji) i bez PIE. Zapewnij CRT (C Runtime) i moduł ładujący PIE dla statycznie połączonych plików wykonywalnych.
- Obsługuje większość funkcji biblioteki C. standardowo z wtyczkami POSIX i niektórymi rozszerzeniami specyficznymi dla systemu, które są wymagane w istniejących aplikacjach.
- Ostrożne podejście do konkretnych rozszerzeń od dostawcy i dodając je tylko wtedy, gdy jest to konieczne. W przypadku obsługi rozszerzeń innych firm proponuje się użycie podejścia projektowego Clang i libc ++.
- Korzystanie z najlepszych praktyk w programowaniu przy użyciu narzędzi LLVM, takie jak stosowanie środków dezynfekujących i eliminacja testów od samego początku.
Wskazał to jeden z aktywnych programistów LLVM dostawa libc jako część zestawu narzędzi LLVM nie jest to bez znaczenia, ale generalnie z taką potrzebą korzystają z biblioteki musl, Jest dobrze napisany, obsługuje wiele architektur i zapewnia niezbędną funkcjonalność, w tym dynamiczne łączenie.
Włączenie Musla do LLVM i jego rozwój jako zsynchronizowanego widelca z głównym projektem może być uzasadniony.
Jego opinię wyraził również autor projektu Musl, który próbował argumentować, dlaczego propozycja Google i włączenie Libc do dostawy LLVM to bardzo złe pomysły:
Tworzenie i utrzymywanie poprawnej, kompatybilnej i wysokiej jakości biblioteki libc jest bardzo trudnym zadaniem. Problem nie polega na ilości kodu, ale na zapewnieniu prawidłowego zachowania.
Oraz trudności z implementacją interfejsu, biorąc pod uwagę ogromne repozytorium aplikacji napisanych w C / C ++, a także aplikacji w innych językach, których środowisko wykonawcze wykorzystuje Libc.
Podejście do czoła bez uwzględnienia niuansów doprowadzi tylko do tego, że wiele istniejących programów nie będzie w stanie współpracować z Libc, ale taki projekt nie będzie interesujący dla konsumentów.
Rozwój korporacyjny może zrujnować Libc, ale powodują powszechne użycie, co spowoduje konieczność dodania hacków w celu zapewnienia kompatybilności w aplikacjach.
Rozwój pod auspicjami otwartego projektu korporacyjnego będzie napędzał pokrycie potrzeb i decyzji firmy ze szkodą dla interesów społeczności.
Na przykład w przypadku zidentyfikowania problemu spowodowanego błędem w innym własnym programie, w rozwoju pod kontrolą, łatwiej jest zagwarantować zgodność Libc z tym błędem, niż sam naprawić błąd.
Apple używa do tych celów widelca BSD libc, a Google używa widelca Fuchsia. Doświadczenie programisty Musla sugeruje, że prawnicy kontaktowali się z nim przede wszystkim w celu wyjaśnienia kwestii licencyjnych.
źródło: http://lists.llvm.org