ar (Unix)

L' archiveur , également connu simplement sous le nom d'ar , est un utilitaire Unix qui conserve des groupes de fichiers sous forme d'un seul fichier d'archive . Aujourd'hui, aril est généralement utilisé uniquement pour créer et mettre à jour des fichiers de bibliothèque statique que l'éditeur de liens ou l'éditeur de liens utilise et pour générer des paquets .deb pour la famille Debian ; il peut être utilisé pour créer des archives à n'importe quelle fin, mais a été largement remplacé par tarà d'autres fins que les bibliothèques statiques. Une implémentation de arest incluse dans l'un des GNU Binutils .

Dans la norme Linux Standard Base (LSB), arcette extension a été déconseillée et devrait disparaître dans une future version de cette norme. La justification avancée était que « la LSB n'inclut pas les utilitaires de développement logiciel et ne spécifie pas les formats de fichiers .o et .a ».

Le format ar n'a jamais été standardisé ; les archives modernes sont basées sur un format commun avec deux variantes principales, BSD et System V (initialement connu sous le nom de COFF , et également utilisé par GNU , ELF et Windows ).

Historiquement, il existe d'autres variantes notamment V6 , V7 , AIX (petit et grand) et Coherent, qui diffèrent toutes considérablement du format commun.

Les archives Debian « . deb » utilisent le format commun.

Un fichier ar commence par un en-tête global , suivi d'un en-tête et d'une section de données pour chaque fichier stocké dans le fichier ar.

Chaque section de données est alignée sur 2 octets. Si elle se termine sur un décalage impair, une nouvelle ligne (' ', 0x0A) est utilisée comme remplissage.

La signature du fichier est un champ unique contenant la chaîne ASCII magique "!<arch>" suivie d'un seul caractère de contrôle LF (0x0A).

Chaque fichier stocké dans une archive ar comprend un en-tête de fichier pour stocker des informations sur le fichier. Le format commun est le suivant. Les valeurs numériques sont codées en ASCII et toutes les valeurs sont complétées à droite avec des espaces ASCII (0x20).

Comme les en-têtes ne contiennent que des caractères ASCII imprimables et des sauts de ligne, une archive contenant uniquement des fichiers texte apparaît toujours comme un fichier texte lui-même.

Les membres sont alignés sur des limites d'octets pairs. « Chaque membre de fichier d'archive commence sur une limite d'octet pair ; une nouvelle ligne est insérée entre les fichiers si nécessaire. Néanmoins, la taille donnée reflète la taille réelle du fichier, à l'exclusion du remplissage. »

En raison des limitations de la longueur et du format des noms de fichiers, les variantes GNU et BSD ont toutes deux conçu des méthodes différentes pour stocker les noms de fichiers longs. Bien que le format commun ne souffre pas du problème de l'année 2038 , de nombreuses implémentations de l'utilitaire ar le sont et devront peut-être être modifiées à l'avenir pour gérer correctement les horodatages supérieurs à 2147483647. Une description de ces extensions se trouve dans libbfd.

Selon le format, de nombreuses implémentations ar incluent une table de symboles globale (alias armap, répertoire ou index) pour une liaison rapide sans avoir à analyser l'intégralité de l'archive pour un symbole. POSIX reconnaît cette fonctionnalité et exige que les implémentations ar disposent d'une -soption pour la mettre à jour. La plupart des implémentations la placent à la première entrée du fichier.

BSD ar stocke les noms de fichiers complétés à droite avec des espaces ASCII. Cela entraîne des problèmes avec les espaces à l'intérieur des noms de fichiers. 4.4BSD ar stocke les noms de fichiers étendus en plaçant la chaîne "#1/" suivie de la longueur du nom de fichier dans le champ du nom de fichier et en stockant le nom de fichier réel devant la section de données.

L'utilitaire BSD ar ne gère traditionnellement pas la construction d'une table de recherche de symboles globaux et délègue cette tâche à un utilitaire distinct nommé ranlib , qui insère un fichier spécifique à l'architecture nommé __.SYMDEFcomme premier membre d'archive. Certains descendants mettent un espace et "SORTED" après le nom pour indiquer une version triée. Une variante 64 bits appelée __.SYMDEF_64existe sur Darwin .

Cependant, depuis que POSIX a ajouté l'exigence de l' -soption en remplacement de ranlib, les implémentations BSD ar plus récentes ont été réécrites pour avoir cette fonctionnalité. FreeBSD en particulier a abandonné le format de table SYMDEF et adopté la table de style System V.

System V ar utilise un caractère '/' (0x2F) pour marquer la fin du nom de fichier ; cela permet d'utiliser des espaces sans utiliser de nom de fichier étendu. Ensuite, il stocke plusieurs noms de fichiers étendus dans la section de données d'un fichier avec le nom "//", cet enregistrement est référencé par les en-têtes futurs. Un en-tête référence un nom de fichier étendu en stockant un "/" suivi d'un décalage décimal au début du nom de fichier dans la section de données du nom de fichier étendu. Le format de ce fichier "//" lui-même est simplement une liste de noms de fichiers longs, chacun séparé par un ou plusieurs caractères LF. Notez que les décalages décimaux sont le nombre de caractères, et non le numéro de ligne ou de chaîne dans le fichier "//". Il s'agit généralement de la deuxième entrée du fichier, après la table des symboles qui est toujours la première.

Le système V ar utilise le nom de fichier spécial « / » pour indiquer que l'entrée de données suivante contient une table de recherche de symboles, qui est utilisée dans les bibliothèques ar pour accélérer l'accès. Cette table de symboles est construite en trois parties qui sont enregistrées ensemble sous forme de données contiguës.

1. Un entier big endian 32 bits, donnant le nombre d'entrées dans la table.
2. Un ensemble d'entiers big endian 32 bits. Un pour chaque symbole, enregistrant la position dans l'archive de l'en-tête du fichier contenant ce symbole.
3. Un ensemble de chaînes terminées par zéro. Chacune est un nom de symbole et apparaît dans le même ordre que la liste des positions de la partie 2.

Certains systèmes System V n'utilisent pas le format décrit ci-dessus pour la table de recherche de symboles. Pour les systèmes d'exploitation tels que HP-UX 11.0, ces informations sont stockées dans une structure de données basée sur le format de fichier SOM .

Le fichier spécial « / » n'est pas terminé par une séquence spécifique ; la fin est supposée une fois que le dernier nom de symbole a été lu.

Pour dépasser la limite de taille de fichier de 4 Gio, certains systèmes d'exploitation comme Solaris 11.2 et GNU utilisent une table de recherche de variantes. Au lieu d'entiers 32 bits, des entiers 64 bits sont utilisés dans les tables de recherche de symboles. La chaîne "/SYM64/" au lieu de "/" est utilisée comme identifiant pour cette table

La variante Windows (PE/COFF) est basée sur la variante SysV/GNU. La première entrée « / » a la même disposition que la table des symboles SysV/GNU. La deuxième entrée est une autre « / », une extension Microsoft qui stocke une table de références croisées de symboles étendue. Celle-ci est triée et utilise des entiers little-endian. La troisième entrée est la donnée de nom long « // » facultative comme dans SysV/GNU.

La version de binutils et Elfutilsar de GNU possède un format d'archive « mince » supplémentaire avec le nombre magique !<mince> . Une archive mince ne contient qu'une table de symboles et des références au fichier. Le format de fichier est essentiellement une archive au format System V où chaque fichier est stocké sans les sections de données. Chaque nom de fichier est stocké sous la forme d'un nom de fichier « long » et ils doivent être résolus comme s'il s'agissait de liens symboliques .

Pour créer une archive à partir des fichiers class1.o , class2.o , class3.o , la commande suivante serait utilisée :

ar rcs libclass.a classe1.o classe2.o classe3.o 

Les linkers Unix, généralement invoqués via le compilateur Ccc , peuvent lire ardes fichiers et en extraire des fichiers objets . Ainsi, si libclass.aest une archive contenant class1.o, class2.oet class3.o, alors

cc main.c libclass.a 

ou (si libclass.a est placé dans le chemin de la bibliothèque standard, comme /usr/local/lib )

cc main.c -lclass 

ou (pendant la liaison)

ld ... main.o -lclass ... 

est le même que :

cc main.c classe1.o classe2.o classe3.o