Uno degli sviluppatori di Google ha presentato sulla mailing list LLVM l'argomento dello sviluppo una libreria C standard multipiattaforma (Libc) nell'ambito del progetto LLVM.
Per diverse ragioni, Google non è soddisfatto dell'attuale libc (glibc, musulmano) e l'azienda è sulla buona strada per sviluppare una nuova implementazione, che intende sviluppare come parte di LLVM. Gli sviluppi di LLVM sono stati recentemente utilizzati come base per la creazione di strumenti di Google.
Lo sviluppo è pianificato per essere graduale, aumentando gradualmente la funzionalità. Si propone che le prime opzioni siano sotto forma di uno strato intermedio tra l'applicazione e il sistema libc, dal quale verranno prese in prestito le funzionalità non realizzate.
Dopo aver raggiunto un certo livello di funzionalità, il nuovo Libc può essere utilizzato come sostituto completo del sistema Libc.
Si prevede di iniziare con il supporto per l'architettura x86-64, Linux e l'associazione statica (il caricamento dinamico, la creazione di pacchetti e le architetture aggiuntive verranno implementate per secondo).
Il progetto è ancora nella fase iniziale di sviluppo, ma gli obiettivi di base sono già stati definiti:
- Modularità e sviluppo secondo la filosofia di fornire una libreria granulare, piuttosto che un insieme monolitico.
- Supporto per collegamenti statici nelle modalità PIE (eseguibili indipendenti dalla posizione) e senza Torta. Fornire CRT (C Runtime) e caricatore PIE per file eseguibili collegati staticamente.
- Supporta la maggior parte delle funzioni della libreria C. standard con plug-in POSIX e alcune estensioni specifiche del sistema richieste nelle applicazioni esistenti.
- Atteggiamento attento verso estensioni specifiche dal provider e aggiungendoli solo quando necessario. Per il supporto di estensioni di terze parti, si propone di utilizzare l'approccio del progetto Clang e libc ++.
- Utilizzo delle migliori pratiche nello sviluppo utilizzando gli strumenti LLVM, come l'applicazione di disinfettanti e l'eliminazione dei test dall'inizio.
Uno degli sviluppatori LLVM attivi lo ha indicato consegna libc come parte del toolkit LLVM non è privo di significato, ma generalmente con tale necessità usano la libreria musl, È ben scritto, supporta più architetture e fornisce le funzionalità necessarie, incluso il collegamento dinamico.
L'incorporazione di Musl in LLVM e il suo sviluppo come fork sincronizzato con il progetto principale può essere giustificato.
La sua opinione è stata espressa anche dall'autore del progetto Musl, che ha cercato di argomentare perché la proposta di Google e l'inclusione di Libc nella consegna di LLVM siano idee pessime:
Sviluppare e mantenere la libc corretta, compatibile e di alta qualità è un compito molto difficile. Il problema non è nella quantità di codice, ma nel fornire il comportamento corretto.
E le difficoltà con l'implementazione dell'interfaccia, considerando l'enorme repository di applicazioni scritte in C / C ++, così come le applicazioni in altri linguaggi il cui runtime è utilizzato da Libc.
L'approccio alla fronte senza tener conto delle sfumature porterà solo al fatto che molti programmi esistenti non saranno in grado di funzionare con Libc, ma un tale progetto non interesserà i consumatori.
Lo sviluppo aziendale può rovinare Libc, ma determinano un uso diffuso, che comporterà la necessità di aggiungere hack per garantire la compatibilità nelle applicazioni.
Lo sviluppo sotto gli auspici di un progetto aziendale aperto guiderà la copertura verso le esigenze e le decisioni dell'azienda, a scapito degli interessi della comunità.
Ad esempio, nel caso di identificare un problema causato da un errore in un altro programma di vostra proprietà, nello sviluppo sotto controllo, è più facile garantire la compatibilità di Libc con questo errore che correggere l'errore stesso.
Apple utilizza il fork libc BSD per questi scopi e Google utilizza il fork Fuchsia. L'esperienza di sviluppatore di Musl suggerisce che gli avvocati lo abbiano contattato principalmente per chiarire i problemi di licenza.
fonte: http://lists.llvm.org