GNU Info
(gcc-295.info)Include Files and VMS
Include Files and VMS
=====================
Due to the differences between the filesystems of Unix and VMS, GCC
attempts to translate file names 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. GCC tries various prefixes
one by one until one of them succeeds:
1. 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.
2. The next prefix tried is `SYS$SYSROOT:[SYSLIB.]'. This is where
VAX-C header files are traditionally stored.
3. 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.
4. If the file specification is not a valid VMS filename (i.e. 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.
5. If none of these strategies succeeds, the `#include' fails.
Include directives of the form:
#include foobar
are a common source of incompatibility between VAX-C and GCC. VAX-C
treats this much like a standard `#include <foobar.h>' directive. That
is incompatible with the ANSI C behavior implemented by GCC: to expand
the name `foobar' as a macro. Macro expansion should eventually yield
one of the two 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 file names as macros with the proper expansion, like this:
#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 that:
#include "foobar"
is actually asking for the file `foobar.h'. GCC 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.
GCC for VMS is distributed with a set of include files that is
sufficient to compile most general purpose programs. Even though the
GCC 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 GCC 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' file name 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.
automatically generated by info2www version 1.2.2.9