Each compilation actually generates two output files. The first of these is the normal object file with a .o extension. The second is a text file containing the dependency information file. It has the same name but with an .ali extension. This file is known as the Ada Library Information (ALI) file.
You normally need not be concerned with the contents of this file, but this section is included in case you want to understand how these files are being used. Each ALI file consists of a series of lines of the form:
The first two lines in the file identify the library output version and Standard version. These are required to be consistent across the entire set of compilation units in your program.
This line indicates the library output version, as defined in gnatvsn.ads. It ensures that separate object modules of a program are consistent. It must be changed if anything changes that would affect successful binding of modules compiled separately. Examples of such changes are modifications in the format of the library information described in this package, modifications to calling sequences, or to the way data is represented.
This line contains information regarding types declared in packages Standard as stored in Gnatvsn.Standard_Version. The purpose (on systems where, for example, the size of Integer can be set by command line switches) is to ensure that all units in a program are compiled with a consistent set of options.
This line is present only for a unit that can be a main program. type is either P for a parameterless procedure or F for a function returning a value of integral type. The latter is for writing a main program that returns an exit status. priority is present only if there was a valid pragma Priority in the corresponding unit to set the main task priority. It is an unsigned decimal integer.
This line is present if a pragma Float_Representation or Long_Float is used to specify other than the default floating-point format. This option applies only to implementations of XGC Ada for the Digital Alpha Systems. The character x is 'I' for IEEE_Float, 'G' for VAX_Float with Long_Float using G_Float, and 'D' for VAX_Float for Long_Float with D_Float.
This line is present if the unit uses tasking directly or indirectly, and has one or more valid xxx_Policy pragmas that apply to the unit. The arguments are as follows
This is present if a valid Locking_Policy pragma applies to the unit. The single character indicates the policy in effect (e.g. "C" for Ceiling_Locking).
This is present if a valid Queuing_Policy pragma applies to the unit. The single character indicates the policy in effect (e.g. "P" for Priority_Queuing).
This is present if a valid Task_Dispatching_Policy pragma applies to the unit. The single character indicates the policy in effect (e.g. "F" for FIFO_Within_Priorities).
Following these header lines, a set of information lines appears for each compilation unit that appears in the corresponding object file. In particular, when a package body or subprogram body is compiled there will be two sets of information, one for the spec and one for the body, with the entry for the body appearing first. This is the only case in which a single ALI file contains more than one unit. Note that subunits do not count as compilation units for this purpose, and generate no library information, because they are inlined. The lines for each compilation unit have the following form:
This line identifies the unit to which this section of the library information file applies. unit-name is the unit name in internal format, as described in package Uname, and source-file is the name of the source file containing the unit.
version is the version given as eight hexadecimal characters with lowercase letters. This value is a hash code that includes contributions from the time stamps of this unit and all its semantically dependent units.
The optional attributes are a series of two-letter codes indicating information about the unit. They give the nature of the unit, and also the information provided by categorization pragmas.
Unit has pragma Elaborate_Body.
Unit has no elaboration routine. All subprogram specs are in this category, as are subprogram bodies if access before elaboration checks are being generated. Package bodies and specs may or may not have NE set, depending on whether or not elaboration code is required.
Unit is a package, rather than a subprogram.
Unit has pragma Pure.
Unit has pragma Preelaborate.
Unit has pragma Remote_Call_Interface.
Unit has pragma Remote_Types.
Unit has pragma Shared_Passive.
Unit is a subprogram, rather than a package.
The attributes may appear in any order, separated by spaces. Another line in the ALI file has the following form:
One of these lines is present for each unit mentioned in an explicit with clause by the current unit. unit-name is the unit name in internal format. source-name is the file name of the file that must be compiled to compile that unit (usually the file for the body, except for packages that have no body). lib-name is the file name of the library information file that contains the results of compiling the unit. The E and EA parameters are present if pragma Elaborate or pragma Elaborate_All, respectively, apply to this unit. ED is used to indicate that the compiler has determined that a pragma Elaborate_All for this unit would be desirable. See Appendix C for details on the use of the ED parameter.
Following the unit information is an optional series of lines that indicate the usage of pragma Linker_Options. For each appearance of pragma Linker_Options in any of the units for which unit lines are present, a line of the form
appears where string is the string from the pragma enclosed in quotes. Within the quotes, the following can occur:
7-bit graphic characters other than " or {
"" (indicating a single " character)
{hh} indicating a character whose code is hex hh
For further details, see Stringt.Write_String_Table_Entry in the file stringt.ads. Note that wide characters in the form {hhhh} cannot be produced, because pragma Linker_Option accepts only String, not Wide_String.
Finally, at the end of the ALI file is a series of lines that indicate the source files on which the compiled units depend. This is used by the binder for consistency checking and look like:
where comments, if present, must be separated from the time stamp by at least one blank. Currently this field is unused.
Blank lines are ignored when the library information is read, and separate sections of the file are separated by blank lines to ease readability. Extra blanks between fields are also ignored.