f78 Include Files and VMS Contents|Index|Previous|Next

Include Files and VMS

Due to the differences between the file systems of Unix and VMS, GNU CC attempts to translate filenames in ‘#include’ into names that VMS will understand. The basic strategy is to prepend a prefix to the specification of the include file, convert the whole filename to a VMS filename, and then try to open the file. GNU CC tries various prefixes one by one until one of them succeeds:

The first prefix is the ‘GNU_CC_INCLUDE:’ logical name: this is where GNU C header files are traditionally stored. If you wish to store header files in non-standard locations, then you can assign the logical ‘GNU_CC_INCLUDE’ to be a search list, where each element of the list is suitable for use with a rooted logical.
The next prefix tried is ‘SYS$SYSROOT:[SYSLIB.]’. This is where VAX-C header files are traditionally stored.
If the include file specification by itself is a valid VMS filename, the preprocessor then uses this name with no prefix in an attempt to open the include file.
If the file specification is not a valid VMS filename (i.e., the specification does not contain a device or a directory specifier, and contains a ‘/’ character), the preprocessor tries to convert it from Unix syntax to VMS syntax. Conversion works like this: the first directory name becomes a device, and the rest of the directories are converted into VMS-format directory names. For example, the name ‘X11/foobar.h’ is translated to ‘X11:[000000]foobar.h’ or ‘X11:foobar.h’, whichever one can be opened. This strategy allows you to assign a logical name to point to the actual location of the header files.
If none of these strategies succeeds, the ‘#include’ fails.

Include directives of the following form.

#include foobar

Such directives are a common source of incompatibility between VAX-C and GNU CC.

VAX-C treats them much like a standard ‘#include <foobar.h>’ directive. That is incompatible with the ANSI C behavior implemented by GNU CC, to expand the name ‘foobar’ as a macro.

Macro expansion should eventually yield one of the two following standard formats for ‘#include’.

#include "file" 
#include < file>

If you have this problem, the best solution is to modify the source to convert the ‘#include’ directives to one of the two standard forms. That will work with either compiler. If you want a quick and dirty fix, define the filenames as macros with the proper expansion, like the following example.

#define stdio <stdio.h>

This will work, as long as the name doesn’t conflict with anything else in the program. Another source of incompatibility is that VAX-C assumes the following.

#include "foobar"

The program is actually asking for the file ‘foobar.h’. GNU CC does not make this assumption, and instead takes what you ask for literally; it tries to read the file ‘foobar’. The best way to avoid this problem is to always specify the desired file extension in your include directives. GNU CC for VMS is distributed with a set of include files that is sufficient to compile most general purpose programs. Even though the GNU CC distribution does not contain header files to define constants and structures for some VMS system-specific functions, there is no reason why you cannot use GNU CC with any of these functions. You first may have to generate or create header files, either by using the public domain utility UNSDL (which can be found on a DECUS tape), or by extracting the relevant modules from one of the system macro libraries, and using an editor to construct a C header file. A ‘#include’ filename cannot contain a DECNET node name. The preprocessor reports an I/O error if you attempt to use a node name, whether explicitly, or implicitly via a logical name.