1 .\" Copyright (c) 2007 Joseph Koshy. All rights reserved.
3 .\" Redistribution and use in source and binary forms, with or without
4 .\" modification, are permitted provided that the following conditions
6 .\" 1. Redistributions of source code must retain the above copyright
7 .\" notice, this list of conditions and the following disclaimer.
8 .\" 2. Redistributions in binary form must reproduce the above copyright
9 .\" notice, this list of conditions and the following disclaimer in the
10 .\" documentation and/or other materials provided with the distribution.
12 .\" This software is provided by Joseph Koshy ``as is'' and
13 .\" any express or implied warranties, including, but not limited to, the
14 .\" implied warranties of merchantability and fitness for a particular purpose
15 .\" are disclaimed. in no event shall Joseph Koshy be liable
16 .\" for any direct, indirect, incidental, special, exemplary, or consequential
17 .\" damages (including, but not limited to, procurement of substitute goods
18 .\" or services; loss of use, data, or profits; or business interruption)
19 .\" however caused and on any theory of liability, whether in contract, strict
20 .\" liability, or tort (including negligence or otherwise) arising in any way
21 .\" out of the use of this software, even if advised of the possibility of
26 .Dd September 07, 2007
31 .Nd format of archives managed by ar(1) and ranlib(1)
35 An archive managed by the
39 utilities is a single file that stores the individual members of the
40 archive along with metadata for each member.
41 There are two major variants of the
43 archive format, the BSD variant and the SVR4/GNU variant.
44 Both variants are described by this manual page.
48 defines constants and structures used to describe the layout
52 archives start with a string of magic bytes
58 The content of the archive follows the magic bytes.
59 Each member stored in the archive is preceded by a fixed size
60 archive header that stores file permissions, last modification
61 time, the owner, and the group of the archived file.
63 Archive headers start at an even byte offset in the archive
65 If the length of the preceding archive member was odd, then an extra
70 The archive header comprises six fixed-size ASCII strings followed
71 by a two character trailer (see
77 char ar_name[16]; /* name */
78 char ar_date[12]; /* modification time */
79 char ar_uid[6]; /* user id */
80 char ar_gid[6]; /* group id */
81 char ar_mode[8]; /* octal file permissions */
82 char ar_size[10]; /* size in bytes */
83 char ar_fmag[2]; /* consistency check */
87 Unused characters in the header are filled with space (ASCII 20H)
89 Each field of the header abuts the next without additional padding.
91 The members of the archive header are as follows:
92 .Bl -tag -width "Va ar_name" -compact
94 This field holds the decimal representation of the
95 modification time, in seconds since the epoch, of the archive
98 This trailer field holds the two characters
102 defined in header file
104 and is used for consistency checks.
106 This field holds the decimal representation of the numeric
107 user id of the creator of the member.
109 This field holds octal representation of the file permissions
112 This field holds the name of an archive member.
113 The usage of this field depends on the format variant:
114 .Bl -tag -width "SVR4/GNU" -compact
116 In the BSD variant, names that are shorter than 16 characters and
117 without embedded spaces are stored directly in this field.
118 If a name has an embedded space, or if it is longer than 16
119 characters, then the string
121 followed by the decimal representation of the length of the file name
122 is placed in this field.
123 The actual file name is stored immediately after the archive header.
124 The content of the archive member follows the file name.
127 field of the header (see below) will then hold the sum of the size of
128 the file name and the size of the member.
130 In the SVR4/GNU variant, names up to 15 characters in length are
131 stored directly in this field, and are terminated by a
133 (ASCII 2FH) character.
134 Names larger than 15 characters in length are stored in a special
135 archive string table member (see
136 .Sx "Archive String Table"
139 field holds the string
141 followed by the decimal representation of the offset in the archive
142 string table of the actual name.
145 In the SVR4/GNU variant, this field holds the decimal representation
146 of actual size in bytes of the archived file.
147 In the BSD variant, for member names that use the
149 field directly, this field holds the decimal representation of the
150 actual size in bytes of the archived member.
151 For member names that use the extension mechanism described above, the
152 field will hold the sum of the sizes, in bytes, of the filename and the
155 This field holds the decimal representation of the numeric
156 group id of the creator of the member.
158 .Ss Archive Symbol Table
159 An archive may additionally contain an archive symbol table
160 used by the link editor,
162 This symbol table has the member name
164 in the BSD variant of the archive format, and the name
166 in the SVR4/GNU variant.
168 The format of the symbol table depends on the format variant:
169 .Bl -tag -width "SVR4/GNU" -compact
171 In the BSD variant, the symbol table has 4 parts encoded in
172 a machine dependent manner:
175 The first part is a binary value containing size in bytes of the
176 second part encoded as a C
179 The second part is a list of
183 Each ranlib structure describes one symbol and comprises of
189 is a zero-based offset into the string table in the fourth part
190 for the symbol's name.
193 is an offset from the beginning of the archive to the start
194 of the archive header for the member that defines the symbol.
196 The third part is a binary value denoting the length of the
197 string table contained in the fourth part.
199 The fourth part is a string table containing NUL-terminated
203 In the SVR4/GNU variant, the symbol table comprises of three parts
204 which follow each other without padding:
207 The first part comprises of a count of entries in the symbol table,
208 stored a 4 byte binary value in MSB first order.
210 The next part is an array of 4 byte file offsets within the archive
211 to archive header for members that define the symbol in question.
212 Each offset in stored in MSB first order.
214 The third part is a string table, that contains NUL-terminated
215 strings for the symbols in the symbol table.
218 .Ss Archive String Table
219 In the SVR4/GNU variant of the
221 archive format, long file names are stored in a separate
222 archive string table and referenced from the archive header
224 Each file name is terminated by the string
226 The string table itself has a name of