Apertura automatica di gcc dall'SDK di AROS

Il compilatore gcc dall'SDK di AROS apre automaticamente le seguenti librerie principali:

• aros.library
• asl.library
• commodities.library
• cybergraphics.library
• datatypes.library
• diskfont.library
• dos.library
• expansion.library
• gadtools.library
• graphics.library
• icon.library
• iffparse.library
• intuition.library
• keymap.library
• layers.library
• locale.library
• muimaster.library (fornita da ZUNE su AROS)
• partition.library
• realtime.library
• utility.library
• workbench.library

Potete disabilitare l'auto apertura di queste librerie specificando il flag -nostdlibs al compilatore gcc. Per le librerie più vecchie fornite da AROS potete usare la corrispondente libreria link-time che avrà cura di aprire la libreria. Quindi, se i vostri programmi usano la reqtools.library aggiungete -lreqtools al comando gcc.

Apertura automatica con il build system di AROS

L'auto apertura delle librerie con il build system è molto a quella con il compilatore gcc di AROS. Analogamente allo specificare l'opzione -l specificate le librerie che usate con il parametro uselibs alle macro %build_prog e %build_module. Maggiori informazioni potete trovarle nel tutorial del build system.

Apertura manuale delle librerie

Per aprire una libreria dovete usare una funzione di exec.library:

#include <proto/exec.h>

struct Library *OpenLibrary( STRPTR name, ULONG version );

OpenLibrary() prende due argomenti:

name

punta al nome della libreria. Normalmente questo è semplicemente il nome, ma può anche essere il path completo (assoluto o relativo) della libreria.

Nota

I path non funzionano con le librerie kernel-based (es. librerie incluse nel kernel). Usate solo path assoluti, se sapete esattamente quello che state facendo!

version

è la versione minima della libreria da aprire. Se la libreria specificata viene trovata, ma la sua versione è inferiore a quella specificata in version, la libreria non verrà aperta, ma verrà restituito un errore. Le versioni sono importanti, perchè le librerie sono concepite per essere espandibili. Alcune funzioni sono disponibili solo a partire da una certa versione della libreria. Per esempio la funzione AllocVec() della exec.library è stata introdotta nella versione 36 della libreria. Se provate a chiamare questa funzione con una versione inferiore della exec.library installata, succederanno cose imprevedibili (molto probabilmente l'applicazione crasherà).

La seguente procedura viene usata per caricare la libreria da aprire:

1. Prima, il nome della libreria viene cercato nella lista delle librerie già caricate. Se questa libreria è stata caricata in memoria precedentemente (es. da un programma diverso) ed è ancora lì, va tutto been e OpenLibrary() torna subito.

   Le librerie nel kernel sono sempre sulla lista delle librerie caricate.

   Nota

   I confronti in questa lista sono case sensitive! Accertatevi di usare il giusto case in name. Normalmente tutti i caratteri in un nome di libreria sono minuscoli.

2. Se la libreria non viene trovata nella lista e in name è stato specificato un path, viene tentata l'apertura del file specificato. Se questa fallisce, OpenLibrary() restituisce un errore.

3. Se viene specificato solo il nome della libreria, questa viene cercata prima nella directory corrente. Se non viene trovata lì, viene cercata nella directory LIBS:.

OpenLibrary() restituisce un puntatore a una struttura, che descrive la libreria (struct Library * definita in exec/libraries.h) o NULL, che significa che l'apertura della libreria è fallita per qualche ragione. Il puntatore risultante deve essere memorizzato per il compilatore. Normalmente viene memorizzato in una variabile della forma: <nomelibreria>Base, es. IntuitionBase per il puntatore alla intuition.library.

Dopo aver aperto la libreria, potete usarne le funzioni semplicemente chiamandole come qualunque altra funzione nel vostro programma. Ma per far sapere al compilatore cosa fare dovete includere il file header specifico per la libreria. Questo è normalmente chiamato proto/<nomelibreria>.h per i compilatori C.

Quando avete finito di usare la libreria dovete chiuderla per liberare le risorse da essa occupate. Questa operazione viene eseguite con:

#include <proto/exec.h>

void CloseLibrary( struct Library *base );

CloseLibrary() chiude la libreria puntata da base. Questo puntatore può anche essere NULL, in quel caso CloseLibrary() non fa nulla.

Dimostreremo l'uso delle librerie creando un piccolo programma, un hello-world grafico. Invece di stampare Hello World! in console, lo faremo apparire in un requester. Una funzione per mostrare un requester è EasyRequestArgs(), che è una funzione di intuition.library. Non parleremo del suo utilizzo qui. Per maggiori informazioni, guardate la sezione sui Requesters.

Esempio d'uso delle librerie:

#include <proto/exec.h>          /* OpenLibrary() e CloseLibrary() */
#include <exec/libraries.h>      /* struct Library */
#include <dos/dos.h>             /* RETURN_OK e RETURN_FAIL */
#include <proto/intuition.h>     /* EasyRequestArgs() */
#include <intuition/intuition.h> /* struct EasyStruct */

/* Questa variabile conterrà il puntatore a intuition.library */
struct Library *IntuitionBase;

int main(int argc, char *argv[])
{
    /* Necessario a EasyRequestArgs(). */
    struct EasyStruct es = {
      sizeof(struct EasyStruct), 0UL,
      "Requester", "Hello World!", "Ok"
    };

    /* Prima, apriamo intuition.library. Ci serve la versione 36 o
       successiva, perchè EasyRequestArgs() è stata introdotta in questa
       versione di intuition.library
    */
    IntuitionBase = OpenLibrary("intuition.library", 36);

    /* Dobbiamo controllare se intuition.library è stata aperta con
       successo. In caso contrario, non dobbiamo chiamarne funzioni, quindi
       usciamo immediatamente con un errore.
    */
    if (!IntuitionBase)
        return RETURN_FAIL;

    /* Dopo aver aperto intuition.library, chiamiamo EasyRequestArgs(). */
    EasyRequestArgs(NULL, &es, NULL, NULL);

    /* Infine, dobbiamo chiudere intuition.library */
    CloseLibrary(IntuitionBase);

    return RETURN_OK;
}

Provate a compilare questo programma. Dovrebbe mostrarvi un grazioso requester hello-world.

Caricamento delle librerie condivise

Su AROS le librerie a collegamento dinamico sono oggetti ELF riallocabili. La prima volta che una libreria viene aperta viene caricata da disco e riallocata con l'indirizzo iniziale su cui è stata caricata. I sistemi AROS e amiga like condividono una grossa regione di memoria tra tutto il codice che gira sul sistema. Questo significa che tutti i programmi possono usare la libreria caricata nella memoria su cui è stata caricata.

Altri sistemi, inclusi Windows e UNIX, hanno un diverso spazio di indirizzamento virtuale per ogni processo. Anche qui l' OS tenta di caricare la libreria condivisa una volta sola e quindi prova a mappare la stessa libreria nello spazio di indirizzo di ognuno dei processi che la usano. La libreria può così essere localizzata a indirizzi diversi in spazi diversi e l'OS deve gestire questa situazione.

Su Windows uno cerca di localizzare la libreria condivisa a una certa locazione di memoria e prova a mapparla nella stessa memoria in ogni processo che usa quella libreria. Se ciò non è possibile la libreria verrà duplicata in memoria. Su molti sistemi UNIX questo problema viene evitato lasciando generare al compilatore del codice indipendente dalla posizione, es. codice che funziona a ogni posizione in memoria senza dover riallocare il codice. A seconda dell'architettura, questo tipo di codice può avere più o meno impatto sulla velocità del codice generato.

Linking dinamico delle funzioni

I programmatori che usano linguaggi a più alto livello per accedere alle funzioni in una libreria condivisa useranno il nome della funzione che vogliono usare. Quando un microprocessore esegue un programma usa indirizzi di memoria per saltare a una certa funzione. A un certo punto il nome usato dal programmatore deve essere tradotto in un indirizzo di memoria.

Su amiga, la traduzione avviene quando il codice viene compilato o quando un programma o un modulo vengono linkati. Ogni libbase di una libreria AROS contiene una tabella di lookup per le funzioni della libreria. Durante la compilazione (o il linking) il nome di una funzione viene tradotto in una posizione in questa tabella dove può essere trovato l'indirizzo della funzione [4]. Le funzioni delle librerie condivise di AROS vengono quindi raggiunte con un livello di indirezione. A seconda delle architetture CPU questo livello di indirezione può avere più o meno influenza sulla velocità del codice. Fortunatamente tipi simili di indirezione sono usati per chiamare le funzioni virtuali delle classi C++ e le moderne CPU sono ottimizzate per gestire le indirezioni senza (grossi) impatti sulla velocità. Quando la tabella di lookup viene legata alla libbase ha bisogno di essere duplicata per le librerie che usano una base per ogni opener.

Su Windows e i sistemi UNIX-like la traduzione di un nome di una funzione to un indirizzo viene fatta quando il programma viene caricato e linkato a run-time con la libreria condivisa [5]. Quando un programma viene linkato in fase di compilazione viene messa una lista di librerie nell'eseguibile insieme a una lista delle funzioni utilizzate. Queste liste sono stringhe ASCII. Quando il programma viene quindi caricato, convertirà i nomi di funzioni ai loro indirizzi (o a un puntatore a una tabella di lookup). Prima vengono aperte le librerie nella lista di librerie, dopo ognuna delle funzioni viene localizzata nelle librerie. Vengono usati meccanismi diversi per il lookup dei nomi delle funzioni. Per esempio su Windows le funzioni disponibili vengono messe in un array ordinato in modo tale che possa venir eseguita una ricerca binaria e su Linux vengono usati gli hash per velocizzare il lookup.

Variabili globali e statiche nelle librerie

Come spiegato nel paragrafo precedente, le librerie condivise di AROS sono caricate e inizializzate una volta sola. Questo ha anche un impatto sul modo con cui vengono gestite le variabili globali e statiche. Potete dichiarare una variabile globale nel sorgente della vostra libreria nel modo seguente:

int globvar;

Questo creerà una variabile globale accessibile in tutte le parti della libreria. Una volta che la libreria condivisa viene caricata in memoria, la tua variabile verrà caricata anch'essa nella memoria occupata dalla libreria e sarà sempre nella stessa locazione fino a quando la libreria non viene scaricata dalla memoria. Le variabili statiche definite in una funzione vengono gestite in modo analogo. Questo significa anche che il codice nella libreria che accede a una variabile globale andrà sempre nella stessa locazione a prescindere da quante volte la libreria viene aperta o da quale programma ha chiamato il codice della libreria. Ottualmente il solo modo di avere una variabile che ha un valore diverso per ogni apertura della libreria è avere una libreria con una base per ogni apertura e memorizzate la libreria in questa base. Al momento anche le variabili globali non vengono esportate dalle librerie condivise di AROS. Possono essere utilizzate solo all'interno della libreria stessa, i programmi che usano una libreria non possono accedere alle variabili globali della libreria direttamente. Per questo le variabili nelle librerie condivise di AROS sono gestite in modo diverso da quelle nelle librerie link-time. Una variabile globale definita in una libreria link-time è anche accessibile dal programma a cui è stata linkata la libreria e ogni programma linkato con la stessa libreria link-time avrà la propria versione della variabile globale.

Su UNIX, le librerie condivise furono introdotte dopo che le librerie link-time furono usate pesantemente. Uno degli obiettivi di progettazione fu quello di rendere il comportamento delle librerie condivise lo stesso di quelle link-time. Per questo viene effettuata una copia delle variabili ogni volta che un programma apre una libreria condivisa. In questo modo, ogni programma che ha aperto una libreria condivisa avrà il proprio insieme di variabili globali. Inoltre, anche le variabili globali di una libreria condivisa vengono automaticamente esportate da quella libreria, cosicchè possano essere usate direttamente nel programma che usa quella libreria.

Su Windows è possibile decidere il comportamento delle variabili globali, se renderlo come quello di AROS o come quello di UNIX, ma di default vengono gestite come quelle di UNIX.

Per portare le librerie condivise su AROS o su Amiga, bisogna tener conto di questa diversa gestione delle variabili. Alcune librerie dipendono da come vengono gestite le variabili sulle librerie condivise in UNIX e Windows e possono essere difficili da portare su AROS.

For porting shared libraries to AROS or amiga this different handling of variables has to be taken into account. Some libraries depend on how variables are handled in UNIX and Windows shared libraries and may be difficult to port to AROS.

Librerie che usano altre librerie

Una libreria può aprire un'altra libreria. Quando una libreria apre un'altra libreria ottiene il libbase per quella libreria. Questo significa che una libreria che ha una base per ogni opener ritornerà un libbase unico a un'altra libreria. Quando un programma apre una libreria con una base per ogni opener otterrà indietro un libbase. Adesso, quando il programma apre una seconda libreria che apre di nuovo la prima libreria allora verrà usato un libbase diverso nella seconda libreria e nel programma. I programmatori di librerie con un libbase per opener devono tenere conto di tutto ciò.

Come discusso precedentemente su UNIX e Windows tutto è basato sui processi. Quando un programma viene caricato viene creato un nuovo processo, ogni libreria condivisa usata in quel processo viene linkata dinamicamente una volta sola a quel processo. Questo significa che un programma e una libreria condivisa che accedono entrambe a una seconda libreria condivisa useranno la stessa istanza di quella libreria condivisa. Inoltre questo comportamento diverso può rendere difficile portare librerie condivise da UNIX/Windows.