AR(5) BSD File Formats Manual AR(5)NAMEar — format of archives managed by ar(1) and ranlib(1)SYNOPSIS
#include <ar.h>
DESCRIPTION
An archive managed by the ar(1) and ranlib(1) utilities is a single file
that stores the individual members of the archive along with metadata for
each member. There are two major variants of the ar(1) archive format,
the BSD variant and the SVR4/GNU variant. Both variants are described by
this manual page.
The header file <ar.h> defines constants and structures used to describe
the layout of these archives.
Archive Layout
ar(1) archives start with a string of magic bytes "!<arch>\n" (constant
ARMAG in header <ar.h>). The content of the archive follows the magic
bytes. Each member stored in the archive is preceded by a fixed size ar‐
chive header that stores file permissions, last modification time, the
owner, and the group of the archived file.
Archive headers start at an even byte offset in the archive file. If the
length of the preceding archive member was odd, then an extra newline
character “\n” is used as padding.
The archive header comprises six fixed-size ASCII strings followed by a
two character trailer (see struct ar_hdr in header file <ar.h>):
struct ar_hdr {
char ar_name[16]; /* name */
char ar_date[12]; /* modification time */
char ar_uid[6]; /* user id */
char ar_gid[6]; /* group id */
char ar_mode[8]; /* octal file permissions */
char ar_size[10]; /* size in bytes */
char ar_fmag[2]; /* consistency check */
};
Unused characters in the header are filled with space (ASCII 20H) charac‐
ters. Each field of the header abuts the next without additional pad‐
ding.
The members of the archive header are as follows:
ar_date This field holds the decimal representation of the modifica‐
tion time, in seconds since the epoch, of the archive member.
ar_fmag This trailer field holds the two characters "`\n" (constant
ARFMAG defined in header file <ar.h>), and is used for con‐
sistency checks.
ar_gid This field holds the decimal representation of the numeric
user id of the creator of the member.
ar_mode This field holds octal representation of the file permissions
for the member.
ar_name This field holds the name of an archive member. The usage of
this field depends on the format variant:
BSD In the BSD variant, names that are shorter than 16
characters and without embedded spaces are stored
directly in this field. If a name has an embedded
space, or if it is longer than 16 characters, then
the string "#1/" followed by the decimal represen‐
tation of the length of the file name is placed in
this field. The actual file name is stored immedi‐
ately after the archive header. The content of the
archive member follows the file name. The ar_size
field of the header (see below) will then hold the
sum of the size of the file name and the size of
the member.
SVR4/GNU In the SVR4/GNU variant, names up to 15 characters
in length are stored directly in this field, and
are terminated by a "/" (ASCII 2FH) character.
Names larger than 15 characters in length are
stored in a special archive string table member
(see Archive String Table below), and the ar_name
field holds the string "/" followed by the decimal
representation of the offset in the archive string
table of the actual name.
ar_size In the SVR4/GNU variant, this field holds the decimal repre‐
sentation of actual size in bytes of the archived file. In
the BSD variant, for member names that use the ar_name field
directly, this field holds the decimal representation of the
actual size in bytes of the archived member. For member
names that use the extension mechanism described above, the
field will hold the sum of the sizes, in bytes, of the file‐
name and the archive member.
ar_uid This field holds the decimal representation of the numeric
group id of the creator of the member.
Archive Symbol Table
An archive may additionally contain an archive symbol table used by the
link editor, ld(1). This symbol table has the member name "__.SYMDEF" in
the BSD variant of the archive format, and the name "/" in the SVR4/GNU
variant.
The format of the symbol table depends on the format variant:
BSD In the BSD variant, the symbol table has 4 parts encoded in a
machine dependent manner:
1. The first part is a binary value containing size in bytes
of the second part encoded as a C “long”.
2. The second part is a list of struct ranlib structures (see
<ranlib.h>). Each ranlib structure describes one symbol
and comprises of two C “long” values. The first “long” is
a zero-based offset into the string table in the fourth
part for the symbol's name. The second “long” is an off‐
set from the beginning of the archive to the start of the
archive header for the member that defines the symbol.
3. The third part is a binary value denoting the length of
the string table contained in the fourth part.
4. The fourth part is a string table containing NUL-termi‐
nated strings.
SVR4/GNU In the SVR4/GNU variant, the symbol table comprises of three
parts which follow each other without padding:
1. The first part comprises of a count of entries in the sym‐
bol table, stored a 4 byte binary value in MSB first
order.
2. The next part is an array of 4 byte file offsets within
the archive to archive header for members that define the
symbol in question. Each offset in stored in MSB first
order.
3. The third part is a string table, that contains NUL-termi‐
nated strings for the symbols in the symbol table.
Archive String Table
In the SVR4/GNU variant of the ar(1) archive format, long file names are
stored in a separate archive string table and referenced from the archive
header for each member. Each file name is terminated by the string
"/\n". The string table itself has a name of "//".
SEE ALSOar(1), ranlib(1), archive(3), elf(3), gelf(3), elf(5)BSD September 07, 2007 BSD
