OpenE2K/gcc
2
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

vms.texi: Blow away false include file section.

Browse Source 
2002-10-02  Nathanael Nerode  <neroden@gcc.gnu.org>

	* doc/vms.texi: Blow away false include file section.

From-SVN: r57747
This commit is contained in:
Nathanael Nerode 2002-10-02 19:17:30 +00:00
parent 6a8a90589c
commit 854ef3909d
2 changed files with 4 additions and 106 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
gcc/ChangeLog
View File

@ -1,3 +1,7 @@
2002-10-02 Nathanael Nerode <neroden@gcc.gnu.org>
* doc/vms.texi: Blow away false include file section.
2002-10-02 Roger Sayle <roger@eyesopen.com>
PR optimization/6627

106
gcc/doc/vms.texi
View File

@ -10,117 +10,11 @@
Here is how to use GCC on VMS@.
@menu
* Include Files and VMS:: Where the preprocessor looks for the include files.
* Global Declarations:: How to do globaldef, globalref and globalvalue with
GCC.
* VMS Misc:: Misc information.
@end menu
@node Include Files and VMS
@section Include Files and VMS
@cindex include files and VMS
@cindex VMS and include files
@cindex header files and VMS
Due to the differences between the filesystems of Unix and VMS, GCC
attempts to translate file names in @samp{#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:
@enumerate
@item
The first prefix is the @samp{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
@samp{GNU_CC_INCLUDE} to be a search list, where each element of the
list is suitable for use with a rooted logical.
@item
The next prefix tried is @samp{SYS$SYSROOT:[SYSLIB.]}. This is where
VAX-C header files are traditionally stored.
@item
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.
@item
If the file specification is not a valid VMS filename (i.e.@: does not
contain a device or a directory specifier, and contains a @samp{/}
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 @file{X11/foobar.h} is
translated to @file{X11:[000000]foobar.h} or @file{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.
@item
If none of these strategies succeeds, the @samp{#include} fails.
@end enumerate
Include directives of the form:
@example
#include foobar
@end example
@noindent
are a common source of incompatibility between VAX-C and GCC@. VAX-C
treats this much like a standard @code{#include <foobar.h>} directive.
That is incompatible with the ISO C behavior implemented by GCC: to
expand the name @code{foobar} as a macro. Macro expansion should
eventually yield one of the two standard formats for @code{#include}:
@example
#include "@var{file}"
#include <@var{file}>
@end example
If you have this problem, the best solution is to modify the source to
convert the @code{#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:
@example
#define stdio <stdio.h>
@end example
@noindent
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:
@example
#include "foobar"
@end example
@noindent
is actually asking for the file @file{foobar.h}. GCC does not
make this assumption, and instead takes what you ask for literally;
it tries to read the file @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 @code{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 @code{#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.
@node Global Declarations
@section Global Declarations and VMS