In
informatica
, una
libreria
, o piu raramente
biblioteca
, e un insieme di
funzioni
o
strutture dati
predefinite e predisposte per essere riutilizzate da altri
programmi
software
attraverso un'opportuna procedura di
collegamento
.
Il termine
libreria
nasce da una fallace trasposizione lessicale dell'inglese
library
(letteralmente,
biblioteca
), ma ormai e cosi diffuso nel vocabolario dei professionisti da essere accettato quale possibile traduzione.
Lo scopo delle librerie software e fornire una collezione di entita di base pronte per l'uso ovvero
riuso di codice
, evitando al
programmatore
di dover riscrivere ogni volta le stesse funzioni o strutture dati e facilitando cosi le operazioni di sviluppo e manutenzione. Questa caratteristica si inserisce quindi nel piu vasto contesto del 'richiamo di codice' all'interno di programmi e applicazioni ed e presente in quasi tutti i linguaggi. I vantaggi principali derivanti dall'uso di un simile approccio sono i seguenti:
- Si puo separare la logica di
programmazione
di una certa applicazione da quella necessaria per la risoluzione di problemi specifici, quali il calcolo di funzioni matematiche o la
gestione delle collezioni
;
- Le entita definite in una certa libreria possono essere riutilizzate da piu applicazioni;
- Si puo modificare la libreria separatamente dal programma, senza limiti alla potenziale vastita di funzioni e strutture dati man mano disponibili nel tempo.
Quasi tutti i
linguaggi di programmazione
supportano il concetto di libreria e moltissimi includono delle librerie
standardizzate
(spesso chiamate proprio
librerie standard
del linguaggio in questione): si tratta di un insieme di funzioni e/o strutture dati che permettono di risolvere i problemi di programmazione piu comuni. Ad esempio, molti linguaggi di programmazione hanno una libreria matematica, che consente di eseguire elevamenti a potenza, il calcolo dei logaritmi e cosi via; funzioni di I/O; funzioni e strutture dati per la gestione di collezioni di oggetti e altre.
Java
e
Dotnet
dispongono di una moltitudine di librerie (
package
) per le piu svariate funzioni, importabili e attivabili nell'ambiente di sviluppo.
Le librerie standard, rispetto a quelle non-standard, consentono una piu agevole
portabilita
degli applicativi che le sfruttano; infatti, ogni produttore di compilatori e tenuto a includere una certa implementazione delle librerie standard; questo significa che le librerie sono potenzialmente supportate da tutte le piattaforme per le quali esiste un compilatore specifico. Viceversa, una libreria non-standard potrebbe non essere supportata su un certo sistema.
Quando il collegamento viene eseguito durante la creazione di un eseguibile o di un altro file oggetto, e noto come
collegamento statico
o
collegamento anticipato
. In questo caso, il collegamento viene solitamente eseguito da un linker, ma puo anche essere eseguito dal compilatore. Una
libreria statica
, nota anche come
archivio
, e pensata per essere collegata staticamente. In origine esistevano solo librerie statiche. Il collegamento statico deve essere eseguito quando vengono ricompilati i moduli.
Tutti i moduli richiesti da un programma a volte sono collegati staticamente e copiati nel
file eseguibile
. Questo processo e il file autonomo risultante e noto come
costruzione statica del programma
. Una costruzione statica potrebbe non richiedere ulteriori riposizionamenti se viene utilizzata la memoria virtuale e non si desidera la
casualizzazione dello spazio degli indirizzi
[1]
.
Una libreria condivisa e un archivio di codice eseguibile che puo essere caricato da piu
processi
contemporaneamente.
Questo genere di librerie viene
collegato
ai programmi in
fase di esecuzione
tramite funzioni dedicate del
sistema operativo
, in particolare il
dynamic linker
.
L'algoritmo di collegamento in fase di esecuzione e alquanto sofisticato e permette, tra le altre cose, di sostituire al volo il codice della libreria senza modificare l'applicazione che lo richiede. Per questo motivo si parla di
collegamento dinamico
e per estensione di
librerie dinamiche
.
Esistono vari formati di librerie condivise tra cui i piu famosi sono:
DLL
utilizzato in
Microsoft Windows
ed
ELF
utilizzato in
BSD
,
Linux
,
Unix
e
derivati
.
La separazione del codice in librerie a collegamento dinamico permette di suddividere il codice eseguibile in parti concettualmente separate, che verranno caricate solo se effettivamente necessarie. Inoltre, una singola libreria, caricata in memoria, puo essere utilizzata da piu programmi, senza la necessita di essere nuovamente caricata, il che permette di risparmiare le risorse del sistema. Questo metodo di
loading on demand
consente, inoltre, installazioni parziali di un sistema software, in cui sono effettivamente presenti sulla
memoria di massa
solo le librerie associate alle funzioni che l'utente desidera utilizzare, come selezionate in fase di installazione.
Un altro vantaggio e la possibilita di aggiornare un programma modificando solo le librerie: inserendo una versione diversa della libreria, che contiene ad esempio dei
bug fix
, tutti i programmi che la usano saranno automaticamente "aggiornati" senza bisogno di essere ricompilati.
Il principale svantaggio e legato al fatto che una nuova versione di una libreria potrebbe effettuare dei cosiddetti
breaking changes
, in modo volontario o, inconsapevolmente, a causa di bug nella nuova versione. Un breaking change e un cambiamento critico nel comportamento del codice della funzione che la rende non piu compatibile con le convenzioni in uso (ad esempio, una funzione che prima restituiva NULL in caso di errore nei parametri e che ora setta
errno
e restituisce un valore non nullo). Ancora piu critico il caso in cui un programma di installazione sovrascriva una DLL con una versione piu vecchia. Altri problemi possono verificarsi in ambiente
COM
. Questi problemi, ben noti ai programmatori
Windows
, sono raggruppati sotto il nome di
DLL hell
(
inferno delle DLL
).
In alcuni sistemi operativi, tipicamente
Unix
e
Unix-like
, e possibile far convivere versioni diverse, fra loro incompatibili, di una stessa libreria, purche siano singolarmente presenti sul
file system
in differenti
percorsi
e sia possibile, in fase di collegamento del programma, l'identificazione della versione corretta di libreria da utilizzare. In questa maniera, i programmi collegati prima dell'installazione della nuova libreria possono continuare ad avvalersi della vecchia versione.
[2]
La maggior parte dei fornitori di minicomputer e mainframe ha avviato progetti per combinare i due, producendo un formato di libreria OOP che potrebbe essere utilizzato ovunque. Tali sistemi erano noti come librerie di oggetti o oggetti distribuiti, se supportavano l'accesso remoto (non tutti lo facevano). COM di Microsoft e un esempio di un tale sistema per uso locale. DCOM, una versione modificata di COM, supporta l'accesso remoto.
Le librerie di classi sono l'equivalente approssimativo
OOP
dei vecchi tipi di librerie di codice. Contengono classi, che descrivono le caratteristiche e definiscono azioni (metodi) che coinvolgono oggetti. Le librerie di classi vengono utilizzate per creare istanze o oggetti con le loro caratteristiche impostate su valori specifici. In alcuni linguaggi OOP, come
Java
, la distinzione e chiara, con le classi spesso contenute nei file di libreria (come il
formato di file
JAR di Java) e gli oggetti istanziati che risiedono solo nella memoria (sebbene potenzialmente in grado di essere resi persistenti in file separati). In altri, come Smalltalk, le librerie di classi sono semplicemente il punto di partenza per un'immagine di sistema che include l'intero stato dell'ambiente, le classi e tutti gli oggetti istanziati.
Un'altra soluzione al problema della libreria deriva dall'utilizzo di eseguibili completamente separati (spesso in una forma leggera) e dal chiamarli utilizzando una chiamata di procedura remota (RPC) su una rete a un altro computer.
Le librerie di generazione del codice sono API di alto livello in grado di generare o trasformare il codice byte per
Java
. Sono usati dalla programmazione orientata agli aspetti, alcuni framework di accesso ai dati e per i test per generare oggetti proxy dinamici. Sono anche usati per intercettare l'accesso al campo
[3]
.
Il sistema archivia
libfoo.a
e file
libfoo.so
in directory come
/lib
,
/usr/lib
o
/usr/local/lib
. I nomi dei file iniziano sempre con
lib
e finiscono con un suffisso di
.a
(archivio, libreria statica) o di
.so
(oggetto condiviso, libreria collegata dinamicamente). Alcuni sistemi potrebbero avere piu nomi per la libreria collegata dinamicamente, con la maggior parte dei nomi per collegamenti simbolici al nome rimanente; quei nomi potrebbero includere la versione principale della libreria o il numero di versione completo; ad esempio, su alcuni sistemi
libfoo.so.2
sarebbe il nome del file per la seconda revisione principale dell'interfaccia della libreria collegata dinamicamente
libfoo
. I file
.la
che a volte si trovano nelle directory della libreria sono archivi
libtool
, non utilizzabili dal sistema in quanto tale.
Il sistema eredita le convenzioni della libreria statica da BSD, con la libreria memorizzata in un file
.a
, e puo utilizzare librerie
.so
collegate dinamicamente in stile (con invece il suffisso
.dylib
). La maggior parte delle librerie in macOS, tuttavia, sono costituite da "framework", collocati all'interno di directory speciali chiamate "bundle" che racchiudono i file e i
metadati
richiesti dalla libreria. Ad esempio, un framework chiamato
MyFramework
verrebbe implementato in un
bundle
chiamato
MyFramework.framework
,
MyFramework.framework/MyFramework
essendo il file di libreria collegato dinamicamente o un collegamento simbolico al file di libreria collegato dinamicamente in
MyFramework.framework/Versions/Current/MyFramework
.
Le librerie a collegamento dinamico di solito hanno il suffisso
*.DLL
,
[4]
sebbene altre estensioni di nomi di file possano identificare librerie collegate dinamicamente per scopi specifici, ad esempio
*.OCX
per le librerie OLE. Le revisioni dell'interfaccia sono codificate nei nomi dei file o astratte utilizzando le interfacce degli oggetti COM. A seconda di come vengono compilati, i file
*.LIB
possono essere librerie statiche o rappresentazioni di librerie collegabili dinamicamente necessarie solo durante la compilazione, note come " librerie di importazione ". A differenza del mondo UNIX, che utilizza estensioni di file diverse, quando si collega al file
.LIB
in Windows bisogna prima sapere se si tratta di una normale libreria statica o di una libreria di importazione. In quest'ultimo caso, un file
.DLL
deve essere presente in fase di esecuzione.
- ^
Christian Collberg, John H. Hartman, Sridivya Babu, Sharath K. Udupa,
SLINKY: Static Linking Reloaded
, su
usenix.org
, Department of Computer Science,
University of Arizona
, 2003.
URL consultato il 17 marzo 2016
(
archiviato
il 23 marzo 2016)
.
- ^
Sito HP, Manuale Digital Unix: Controllo versione librerie in fase di caricamento
- ^
Code Generation Library
, su
sourceforge.net
,
Source Forge
.
URL consultato il 3 marzo 2010
(
archiviato
il 12 gennaio 2010)
.
≪Byte Code Generation Library is high level API to generate and transform JAVA byte code. It is used by AOP, testing, data access frameworks to generate dynamic proxy objects and intercept field access.≫
- ^
Christine Bresnahan e Richard Blum,
LPIC-1 Linux Professional Institute Certification Study Guide: Exam 101-400 and Exam 102-400
, John Wiley & Sons, 27 aprile 2015, p. 82,
ISBN
978-1-119-02118-6
.
URL consultato il 3 settembre 2015
(
archiviato
il 24 settembre 2015)
.
≪Linux shared libraries are similar to the dynamic link libraries (DLLs) of Windows. Windows DLLs are usually identified by .dll filename extensions.≫