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 doesnt 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 always to 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.
Top|Contents|Index|Previous|Next