Salah sawijining pangembang saka Google ing mailing list LLVM babagan pangembangan perpustakaan C standar multi-platform (Libc) minangka bagéan saka project LLVM. Kanggo sawetara alasan, Google ora wareg karo libc saiki (glibc, musl) lan perusahaan ing dalan kanggo ngembangake implementasi anyar, sing diusulake kanggo dikembangake minangka bagéan saka LLVM.
Pangembangan LLVM bubar digunakake minangka basis kanggo mbangun alat perakitan Google. Ide utama yaiku yen Google wis wiwit ngembangake libc, mula kenapa ora langsung ngembangake sistem kasebut minangka bagean saka LLVM, sing wis nawakake perpustakaan standar dhewe kanggo C++ (Libc++), nanging ora duwe perpustakaan standar sing padha kanggo C. (libc).
Pangembangan direncanakake ditindakake kanthi bertahap, kanthi bertahap nambah fungsi. Opsi pisanan diusulake kanggo dirancang minangka lapisan antarane aplikasi lan sistem Libc, saka ngendi fitur sing durung dileksanakake bakal dipinjam. Sawise tekan tingkat fungsi tartamtu, Libc anyar bisa digunakake minangka panggantos lengkap kanggo sistem Libc. Kita rencana miwiti kanthi dhukungan kanggo arsitektur x86-64, Linux, lan link statis (loading dinamis, link, lan arsitektur tambahan bakal dileksanakake kaping pindho).
Proyek kasebut isih ana ing tahap wiwitan pangembangan, nanging tujuan dhasar wis ditemtokake:
- Modularitas lan pangembangan sesuai karo filosofi ngirim perpustakaan granular tinimbang pesawat monolitik;
- Dhukungan kanggo ngubungake statis ing mode (Executables posisi-independen) lan tanpa PIE. Nyedhiyakake CRT (C runtime) lan PIE loader kanggo eksekusi statis sing disambung;
- Dhukungan kanggo umume fungsi perpustakaan C standar, kanthi tambahan POSIX lan sawetara ekstensi khusus sistem sing dibutuhake dening aplikasi sing wis ana;
- Ati-ati karo ekstensi khusus vendor lan mung tambahake yen perlu. Babagan dhukungan kanggo ekstensi pihak katelu, disaranake nggunakake pendekatan proyek Clang lan libc ++;
- Nggunakake praktik paling apik ing pangembangan nggunakake toolkit LLVM, kayata nggunakake sanitizer lan tes fuzz wiwit wiwitan.
Salah sawijining pangembang LLVM aktif Iku cetha yen iku ndadekake pangertèn kanggo kapal libc minangka bagéan saka toolkit LLVM, nanging biasane, yen perlu kuwi, padha nggunakake musl perpustakaan, kang uga ditulis, ndhukung macem-macem arsitektur, lan nyedhiyani fungsi perlu, kalebu support kanggo dinamis. ngubungake. Bisa uga ditrapake kanggo nempelake musl menyang LLVM lan ngembangake minangka garpu sing disinkronake karo proyek utama.
Pendapat sampeyan uga Penulis proyek Musl, sing nyoba mbantah kenapa proposal Google lan kalebu Libc ing distribusi LLVM minangka ide sing ala banget:
- Ngembangake lan njaga Libc sing bener, kompatibel, lan berkualitas minangka tugas sing angel banget. Masalahe ora ana ing jumlah kode, nanging kanggo mesthekake prilaku sing bener lan kesulitan kanggo ngleksanakake antarmuka, kanthi nganggep lapisan aplikasi sing gedhe banget sing wis ditulis ing C / C ++, uga aplikasi ing basa liya, wektu sing digunakake. dening Libc. Pendekatan langsung tanpa nggatekake nuansa mung bakal nyebabake kasunyatan manawa akeh program sing wis ana ora bakal bisa digarap Libc, nanging proyek kasebut ora bakal dadi kapentingan kanggo konsumen.
- Pangembangan perusahaan bisa ngrusak Libc, nanging nyurung panggunaan sing nyebar, nyebabake perlu kanggo nambah hacks kanggo njamin kompatibilitas ing aplikasi. Pangembangan ing sangisore proyek open source perusahaan bakal narik kemul menyang kabutuhan lan solusi perusahaan, kanggo ngrusak kapentingan masyarakat. Contone, yen sampeyan ngenali masalah sing disebabake bug ing program liyane, ing kontrol pembangunan luwih gampang kanggo mesthekake yen Libc kompatibel karo bug iki saka kanggo ndandani bug dhewe. Apple nggunakake garpu libc BSD kanggo tujuan kasebut, lan Google nggunakake garpu musl ing Fuchsia. Pengalaman pangembang musl yaiku dheweke dikontak utamane dening pengacara kanggo njlentrehake masalah lisensi, nanging ora tau dikontak kanggo njlentrehake rincian teknis sadurunge nggawe owah-owahan sing ora ana guna lan ngganggu cabang-cabange.
- Ora ana monokultur ing pangembangan libc lan fokus ing standar sing didhukung konsensus tinimbang kontrol individu, sing ndadekake pangembang aplikasi nggunakake standar tinimbang diikat karo implementasine tartamtu. Pramila penulis musl nglawan inklusi perpustakaan ing LLVM, uga nglawan pangembangan libc ing LLVM, amarga ing kasus iki sifat independen libc ilang lan implementasine tartamtu dadi solusi kelas siji kanggo LLVM, lan kabeh liyane dadi solusi kelas loro.
Source: opennet.ru