Chapter Contents

Previous

Next

Files

As shown in Cross-Platform Compiler Architecture, the cross-platform compiler actually consists of executable files. The sascc370 and sasCC370 compiler drivers are responsible for processing the options you specify on the command line and controlling the compilation of C and C++ programs. The other executable files are the translator, parser, global optimizer, code generator, prelinker, and the object module disassembler. The location of these files is site-specific.

The cross-platform compiler also supplies and uses additional files that are located in other directories. These files are described in Additional Files Required .

Additional Files Required

Files		Location
Library		The resident portion of the SAS/C C and C++ libraries is located in the ar370 archives found in the lib directory. Since the transient portion of the SAS/C C and C++ libraries contains routines that must be loaded during program execution, the transient portion must be located on the mainframe with your executable load module. Different ar370 archives are provided for different mainframe target environments.
Header		The standard SAS/C C and C++ header files are located in an include directory. Additional directory locations for include files can be specified.
Input		Your source code, compiled objects, or ar370 archive input files can be located in any directory you choose.
Output		Your compiled or prelinked output can be directed to files in any directory you choose.

The next four sections of this chapter provide additional information about the library, include, input, and output files used by the cross-platform compiler.

Library Files

The SAS/C C and C++ libraries contain both resident and transient routines. (They also provide all-resident and SPE routines that can be used in specialized applications.) Resident routines are incorporated into your program before it is executed. Transient routines are dynamically loaded during program execution.

Resident Library Routines

The resident libraries, libc.a for C and libcxx.a for C++, contain routines that are prelinked with your application. Because these routines are added to your program during prelinking, resident library routines are not dynamically loaded during program execution. The resident library is specific to your target: MVS, CMS (VM/ESA Mode), or CMS (System/370 mode).

Transient Library Routines

The transient library is a collection of system-dependent routines that are loaded as needed by a program during execution. For example, before the program's main function is entered, the command line must be parsed and the argv vector created. Because the command line parsing routine is only needed once, during program start-up, the program initialization routine dynamically loads it from the transient library and unloads it (freeing the memory it required as well) when it is no longer needed.

All-resident Library Routines

In most programming situations, the dynamic loading and unloading of routines from the transient library makes the best use of available resources. User storage is not occupied by unused code, and when the support routines are installed in shared memory, many users can access a single copy of the routine. Also, the load module is much smaller because it contains only a small percentage of the required code.

However, in certain specialized applications and environments, it may be desirable to force the program load module to contain a private copy of all the required support routines. These programs can be characterized as all-resident programs because no transient library routines are used. In order to create an all-resident program, your program must include routines from the all-resident library.

The -Tallres compiler option is used to specify an all-resident program. You can also invoke cool directly, specifying the location of the all-resident library, libdir/ libares.a , as an argument to cool .

SPE Library Routines

The SAS/C SPE library, libspe.a , provides resident routines that support the C Systems Programming Environment (SPE). The -Tspe compiler option can be used to specify an SPE program. You can invoke cool directly, specifying the location of the SPE library as an argument to cool .

Header Files

C and C++ source files take advantage of preprocessor support for including auxiliary source in a compilation by using the #include mechanism. The cross-platform compiler C and C++ preprocessors interpret #include statements that cause auxiliary files to be included as part of the source being compiled.

Auxiliary source files that are not provided as part of the SAS/C C and C++ libraries are considered to be user header files, and are typically enclosed in double quotes. For example

#include "error_messages.h"

Auxiliary files that are provided with the SAS/C C and C++ libraries are called library header files or system header files, and are typically enclosed in angle brackets. For example

#include <stdio.h>

The library header files are installed with the product in the include subdirectory on UNIX and in the installdir\include subdirectory on Windows 95 and Windows NT. This location is called the system directory on all three platforms.

When the SAS/C C and C++ preprocessors encounter a #include statement, the auxiliary file to be included must be located. The compilers search for the named file in a way that is typical of UNIX compilers. To modify the search order, use the -Knousearch option. The following describes the search performed by the preprocessor.

• If the filename in the #include statement is a complete pathname, beginning from the root directory (/), then no other searching is performed. If the C or C++ system is unable to read the named file, an error is produced.

• If the file was enclosed in double quotes and the -Knousearch option was not specified, the search proceeds as follows. Look in:
  1. The directory of the source file containing the #include statement.

  2. Any directories specified by the -I compiler option. This search is done in the order that the -I options appear on the command line.

  3. The system directory.

• If the file was enclosed in angle brackets and the -Knousearch option was not specified, the search proceeds as follows. Look in:
  1. Any directories specified by the -I compiler option. This search is done in the order that the -I options appear on the command line.

  2. The system directory.

• If the file was enclosed in double quotes and the -Knousearch option was specified, the SAS/C C preprocessors take the following steps to locate the named file. Look in:
  1. The current working directory.

  2. Any directories specified by the -I compiler option. This search is done in the order that the -I options appear on the command line.

  3. The directory of the source file containing the #include statement.

  4. The system directory.

• If the file was enclosed in angle brackets and the -Knousearch option was specified, the SAS/C C preprocessors take the following steps to locate the named file. Look in:
  1. The current working directory.

  2. The system directory.

The search order described in this section is traditional with UNIX C compilers, and therefore meshes well with many of the programming tools commonly used under the UNIX operating system, such as make .

Adding Directories to the Search Path under UNIX

The -I compiler option in the SAS/C Cross-Platform Compiler enables you to specify additional directories that are searched before the standard include-file search list. For example, the following command causes the cross-platform compiler to search the /u/userid/branch_bank/headers directory for header files:

sascc370 -I/u/userid/branch_bank/headers
   debits.c credits.c

In this example, debits.c or credits.c could contain the statement

#include "transactions.h"

Adding Directories to the Search Path under a Windows Environment

When the SAS/C C and C++ preprocessors encounter a #include statement, the auxiliary file to be included must be located. The compiler searches the SASCINCLUDE environment variable, which was automatically defined at installation. You have two optio ns for adding additional user directories to the search path. Depending on your desired search order, you can either prefix or append the SASCINCLUDE environment variable in your installdir\host\wnt\bin\sascc.cfg configuration file. Or, you can use the -I compiler option in the SAS/C Cross-Platform Compiler to enable you to specify additional directories that are searched before the standard include-file search list. For example, either of the following solutions causes the cross-platform compiler to first search the c:\user\branch_bank\headers directory, then the system directory, for header files:

sascc370 -Ic:\user\branch_bank\headers
   debits.c credits.c

Or, you could change the sascc.cfg file to explicitly prefix the user header file directory to the INCLUDE statement:

INCLUDE=c:\user\branch_bank\headers;
   %SASCINCLUDE%

In these two examples, debits.c and credits.c could contain the statement:

#include "transactions.h"

Under a Windows environment, the sascc370 compiler driver accepts C source, C++ source, and previously compiled objects. Under UNIX the the sascc370 compiler driver accepts C source and previously compiled objects, and the sasCC370 compiler driver accepts C++ source and previously compiled objects. However, the sascc370 compiler driver can accept C++ source under UNIX if you specify -cxx on the sascc370 command line.

sascc370 Input Files

The sascc370 compiler driver accepts the following input files.

sascc370 Input Files

Input Files	Description
C Source Files	uncompiled C source code, identified by a .c filename extension.
C++ Source Files	uncompiled C++ source code, identified by .cpp , .cxx , or .C .
Compiled Object Files	contain previously compiled object code. Identified by a .o filename extension.
Archive Libraries	ar370 archive files. Identified by a .a filename extension.

The sascc370 compiler driver examines the filename extension to determine whether the file contains source code ( .c ) or compiled objects ( .o or .a ). The driver then takes action based on the compiler options and the types of input files specified on the command line. For a .c file, the following actions are taken:

1. Invoke the cross-platform compiler to produce a .o object file.

2. Invoke cool with the system ar370 archive, libc.a , and the .o object file to produce a prelinked object file.

The output files produced by this sequence are described in Output Files .

sasCC370 Input Files

The sasCC370 compiler driver accepts the following input files.

sasCC370 Input Files

Input Files		Description
C++ Source Files		uncompiled C++ source code, identified by a .cpp , .cxx , .C , or .c filename extension.
Compiled Object Files		contain previously compiled object code. Identified by a .o filename extension.
Archive Libraries		ar370 archive files. Identified by a .a filename extension.

The sasCC370 compiler driver examines the filename extension to determine whether the file contains source code ( .cpp , .cxx , .C , or .c ) or compiled objects ( .o or .a ). The driver then takes action based on the compiler options and the types of input files specified on the command line. For a .c file, the following actions are taken:

1. Invoke the cross-platform compiler to produce a .o object file.

2. Invoke cool with the system ar370 archive, libc.a , and the .o object file to produce a prelinked object file.

The output files produced by this sequence are described in Output Files .

Output Files

Depending on how they are invoked, the sascc370 and sasCC370 compiler drivers produce any of the following output file types:

sascc370 Output Files

Output Files		Contents
Object Files		unlinked object code and are identified by a .o filename extension.
Prelinked Output Files		object code that has been prelinked by cool . By default, the prelinked output is written to a.out . The -o compiler option is used to direct the output to another file.
Preprocessed Source Files		source code that has been preprocessed and are identified by a .i extension. Preprocessed source code has all the macros and #include files expanded. These files are generated by invoking the sascc370 compiler driver with the -P option.
Debugger Files		information used by the SAS/C Debugger and are identified by a .dbg370 filename extension. These files are produced if the -g compiler option is specified.
OMD Output Files		output from the Object Module Disassembler. These files are identified by a .omd filename extension. See Using the Global Optimizer and the Object Module Disassembler for more information.
Listing Files		output listings and are identified by a .lst filename extension. The -Klisting compiler option is used to specify a particular listing file.

The prelinked object file can be copied to the mainframe, where it is then submitted to the linkage editor, which accomplishes the final linking and generates an executable module. Note that your output files will be targeted for an MVS environment by default. Use either the -Tcms370 or the -Tpcms370 compiler options to generate output files that are compatible with the CMS environment. Use the -Tcics compiler option to generate output files that are compatible with the CICS environment.

The .dbg370 debugger files are required to debug your program with the SAS/C Debugger. See Cross-Debugging for more information about using the SAS/C Debugger in the cross-platform development environment.

Output Filename Generation

Unless you use the -o compiler option to specify an output filename, the base filename of the source file will be used to generate the base filenames of the output object and listing files. For example, suppose you invoked the cross-platform compiler with the following command:

sascc370 -Kilist students.c

In this example, the -Kilist option specifies that a header file listing should be generated. The students.c file contains uncompiled source code that includes a header file that will be printed to the output listing. The following output files are produced:

Example Output Files

File		Description
a.out		prelinked output file
students.lst		listing file containing the source code for the included header file.
students.o		compiled file containing object code.

Using -o with a Single Source File

If file students.c is compiled with the -o option, the output object and listing filenames are formed with the specified base name. For example, suppose the cross-platform compiler is invoked as follows:

sascc370 -o roster -Kilist students.c

In this case, the following output files are generated:

Example Output Files

File		Description
roster		prelinked output file
students.lst		listing file containing the source code for the included header file.
students.o		compiled file containing object code.

Notice that the a.out file is not generated in this case; instead, the prelinked object is written to the file specified with -o .

Using -o with Multiple Source Files

With multiple input files, the base name of each source file is used to generate the base of the .o and .lst filenames associated with the source file. For example,

sascc370 -o acct_bal -Kilist debit.c credit.c

In this case, the following output files are generated:

Example Output Files

File		Description
acct_bal		prelinked output file
debit.lst		listing file containing the source code for the header file included by debit.c .
credit.lst		listing file containing the source code for the header file included by credit.c .
credit.o		compiled file containing object code.
debit.o		compiled file containing object code.

Chapter Contents

Previous

Next

Top of Page

Copyright © 1998 by SAS Institute Inc., Cary, NC, USA. All rights reserved.