Files
oldlinux-files/Ref-docs/manual gcc2.95.3/gcc_11.html
2024-02-19 00:21:47 -05:00

447 lines
24 KiB
HTML

<HTML>
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<!-- Created on March, 17 2001 by texi2html 1.64 -->
<!--
Written by: Lionel Cons <Lionel.Cons@cern.ch> (original author)
Karl Berry <karl@freefriends.org>
Olaf Bachmann <obachman@mathematik.uni-kl.de>
and many others.
Maintained by: Olaf Bachmann <obachman@mathematik.uni-kl.de>
Send bugs and suggestions to <texi2html@mathematik.uni-kl.de>
-->
<HEAD>
<TITLE>Using and Porting the GNU Compiler Collection (GCC): VMS</TITLE>
<META NAME="description" CONTENT="Using and Porting the GNU Compiler Collection (GCC): VMS">
<META NAME="keywords" CONTENT="Using and Porting the GNU Compiler Collection (GCC): VMS">
<META NAME="resource-type" CONTENT="document">
<META NAME="distribution" CONTENT="global">
<META NAME="Generator" CONTENT="texi2html 1.64">
</HEAD>
<BODY LANG="" BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#0000FF" VLINK="#800080" ALINK="#FF0000">
<A NAME="SEC142"></A>
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_10.html#SEC141" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_10.html#SEC141"> &lt; </A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_11.html#SEC143" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_11.html#SEC143"> &gt; </A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT"> &nbsp; <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_2.html#SEC2" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_2.html#SEC2"> &lt;&lt; </A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc.html#SEC_Top" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc.html#SEC_Top"> Up </A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_12.html#SEC146" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_12.html#SEC146"> &gt;&gt; </A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT"> &nbsp; <TD VALIGN="MIDDLE" ALIGN="LEFT"> &nbsp; <TD VALIGN="MIDDLE" ALIGN="LEFT"> &nbsp; <TD VALIGN="MIDDLE" ALIGN="LEFT"> &nbsp; <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc.html#SEC_Top" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc.html#SEC_Top">Top</A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_toc.html#SEC_Contents" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_toc.html#SEC_Contents">Contents</A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_24.html#SEC261" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_24.html#SEC261">Index</A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_abt.html#SEC_About" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_abt.html#SEC_About"> ? </A>]</TD>
</TR></TABLE>
<H1> 11. Using GCC on VMS </H1>
<!--docid::SEC142::-->
<P>
Here is how to use GCC on VMS.
</P><P>
<BLOCKQUOTE><TABLE BORDER=0 CELLSPACING=0>
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="gcc_11.html#SEC143" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_11.html#SEC143">11.1 Include Files and VMS</A></TD><TD>&nbsp;&nbsp;</TD><TD ALIGN="left" VALIGN="TOP">Where the preprocessor looks for the include files.</TD></TR>
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="gcc_11.html#SEC144" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_11.html#SEC144">11.2 Global Declarations and VMS</A></TD><TD>&nbsp;&nbsp;</TD><TD ALIGN="left" VALIGN="TOP">How to do globaldef, globalref and globalvalue with
GCC.</TD></TR>
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="gcc_11.html#SEC145" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_11.html#SEC145">11.3 Other VMS Issues</A></TD><TD>&nbsp;&nbsp;</TD><TD ALIGN="left" VALIGN="TOP">Misc information.</TD></TR>
</TABLE></BLOCKQUOTE>
<P>
<A NAME="Include Files and VMS"></A>
<HR SIZE="6">
<A NAME="SEC143"></A>
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_11.html#SEC142" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_11.html#SEC142"> &lt; </A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_11.html#SEC144" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_11.html#SEC144"> &gt; </A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT"> &nbsp; <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_11.html#SEC142" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_11.html#SEC142"> &lt;&lt; </A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_11.html#SEC142" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_11.html#SEC142"> Up </A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_12.html#SEC146" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_12.html#SEC146"> &gt;&gt; </A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT"> &nbsp; <TD VALIGN="MIDDLE" ALIGN="LEFT"> &nbsp; <TD VALIGN="MIDDLE" ALIGN="LEFT"> &nbsp; <TD VALIGN="MIDDLE" ALIGN="LEFT"> &nbsp; <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc.html#SEC_Top" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc.html#SEC_Top">Top</A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_toc.html#SEC_Contents" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_toc.html#SEC_Contents">Contents</A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_24.html#SEC261" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_24.html#SEC261">Index</A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_abt.html#SEC_About" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_abt.html#SEC_About"> ? </A>]</TD>
</TR></TABLE>
<H2> 11.1 Include Files and VMS </H2>
<!--docid::SEC143::-->
<P>
<A NAME="IDX415"></A>
<A NAME="IDX416"></A>
<A NAME="IDX417"></A>
Due to the differences between the filesystems of Unix and VMS, GCC
attempts to translate file names in <SAMP>`#include'</SAMP> 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:
</P><P>
<OL>
<LI>
The first prefix is the <SAMP>`GNU_CC_INCLUDE:'</SAMP> 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'</SAMP> to be a search list, where each element of the
list is suitable for use with a rooted logical.
<P>
<LI>
The next prefix tried is <SAMP>`SYS$SYSROOT:[SYSLIB.]'</SAMP>. This is where
VAX-C header files are traditionally stored.
<P>
<LI>
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.
<P>
<LI>
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>`/'</SAMP>
character), the preprocessor tries to convert it from Unix syntax to
VMS syntax.
<P>
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 <TT>`X11/foobar.h'</TT> is
translated to <TT>`X11:[000000]foobar.h'</TT> or <TT>`X11:foobar.h'</TT>,
whichever one can be opened. This strategy allows you to assign a
logical name to point to the actual location of the header files.
</P><P>
<LI>
If none of these strategies succeeds, the <SAMP>`#include'</SAMP> fails.
</OL>
<P>
Include directives of the form:
</P><P>
<TABLE><tr><td>&nbsp;</td><td class=example><pre>#include foobar
</pre></td></tr></table></P><P>
are a common source of incompatibility between VAX-C and GCC. VAX-C
treats this much like a standard <CODE>#include &#60;foobar.h&#62;</CODE> directive.
That is incompatible with the ANSI C behavior implemented by GCC: to
expand the name <CODE>foobar</CODE> as a macro. Macro expansion should
eventually yield one of the two standard formats for <CODE>#include</CODE>:
</P><P>
<TABLE><tr><td>&nbsp;</td><td class=example><pre>#include "<VAR>file</VAR>"
#include &#60;<VAR>file</VAR>&#62;
</pre></td></tr></table></P><P>
If you have this problem, the best solution is to modify the source to
convert the <CODE>#include</CODE> 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:
</P><P>
<TABLE><tr><td>&nbsp;</td><td class=example><pre>#define stdio &#60;stdio.h&#62;
</pre></td></tr></table></P><P>
This will work, as long as the name doesn't conflict with anything else
in the program.
</P><P>
Another source of incompatibility is that VAX-C assumes that:
</P><P>
<TABLE><tr><td>&nbsp;</td><td class=example><pre>#include "foobar"
</pre></td></tr></table></P><P>
is actually asking for the file <TT>`foobar.h'</TT>. GCC does not
make this assumption, and instead takes what you ask for literally;
it tries to read the file <TT>`foobar'</TT>. The best way to avoid this
problem is to always specify the desired file extension in your include
directives.
</P><P>
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</CODE> (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.
</P><P>
A <CODE>#include</CODE> 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.
</P><P>
<A NAME="Global Declarations"></A>
<HR SIZE="6">
<A NAME="SEC144"></A>
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_11.html#SEC143" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_11.html#SEC143"> &lt; </A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_11.html#SEC145" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_11.html#SEC145"> &gt; </A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT"> &nbsp; <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_11.html#SEC145" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_11.html#SEC145"> &lt;&lt; </A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_11.html#SEC142" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_11.html#SEC142"> Up </A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_12.html#SEC146" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_12.html#SEC146"> &gt;&gt; </A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT"> &nbsp; <TD VALIGN="MIDDLE" ALIGN="LEFT"> &nbsp; <TD VALIGN="MIDDLE" ALIGN="LEFT"> &nbsp; <TD VALIGN="MIDDLE" ALIGN="LEFT"> &nbsp; <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc.html#SEC_Top" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc.html#SEC_Top">Top</A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_toc.html#SEC_Contents" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_toc.html#SEC_Contents">Contents</A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_24.html#SEC261" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_24.html#SEC261">Index</A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_abt.html#SEC_About" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_abt.html#SEC_About"> ? </A>]</TD>
</TR></TABLE>
<H2> 11.2 Global Declarations and VMS </H2>
<!--docid::SEC144::-->
<P>
<A NAME="IDX418"></A>
<A NAME="IDX419"></A>
<A NAME="IDX420"></A>
<A NAME="IDX421"></A>
GCC does not provide the <CODE>globalref</CODE>, <CODE>globaldef</CODE> and
<CODE>globalvalue</CODE> keywords of VAX-C. You can get the same effect with
an obscure feature of GAS, the GNU assembler. (This requires GAS
version 1.39 or later.) The following macros allow you to use this
feature in a fairly natural way:
</P><P>
<TABLE><tr><td>&nbsp;</td><td class=smallexample><FONT SIZE=-1><pre>#ifdef __GNUC__
#define GLOBALREF(TYPE,NAME) \
TYPE NAME \
asm ("_$$PsectAttributes_GLOBALSYMBOL$$" #NAME)
#define GLOBALDEF(TYPE,NAME,VALUE) \
TYPE NAME \
asm ("_$$PsectAttributes_GLOBALSYMBOL$$" #NAME) \
= VALUE
#define GLOBALVALUEREF(TYPE,NAME) \
const TYPE NAME[1] \
asm ("_$$PsectAttributes_GLOBALVALUE$$" #NAME)
#define GLOBALVALUEDEF(TYPE,NAME,VALUE) \
const TYPE NAME[1] \
asm ("_$$PsectAttributes_GLOBALVALUE$$" #NAME) \
= {VALUE}
#else
#define GLOBALREF(TYPE,NAME) \
globalref TYPE NAME
#define GLOBALDEF(TYPE,NAME,VALUE) \
globaldef TYPE NAME = VALUE
#define GLOBALVALUEDEF(TYPE,NAME,VALUE) \
globalvalue TYPE NAME = VALUE
#define GLOBALVALUEREF(TYPE,NAME) \
globalvalue TYPE NAME
#endif
</FONT></pre></td></tr></table></P><P>
(The <CODE>_$$PsectAttributes_GLOBALSYMBOL</CODE> prefix at the start of the
name is removed by the assembler, after it has modified the attributes
of the symbol). These macros are provided in the VMS binaries
distribution in a header file <TT>`GNU_HACKS.H'</TT>. An example of the
usage is:
</P><P>
<TABLE><tr><td>&nbsp;</td><td class=example><pre>GLOBALREF (int, ijk);
GLOBALDEF (int, jkl, 0);
</pre></td></tr></table></P><P>
The macros <CODE>GLOBALREF</CODE> and <CODE>GLOBALDEF</CODE> cannot be used
straightforwardly for arrays, since there is no way to insert the array
dimension into the declaration at the right place. However, you can
declare an array with these macros if you first define a typedef for the
array type, like this:
</P><P>
<TABLE><tr><td>&nbsp;</td><td class=example><pre>typedef int intvector[10];
GLOBALREF (intvector, foo);
</pre></td></tr></table></P><P>
Array and structure initializers will also break the macros; you can
define the initializer to be a macro of its own, or you can expand the
<CODE>GLOBALDEF</CODE> macro by hand. You may find a case where you wish to
use the <CODE>GLOBALDEF</CODE> macro with a large array, but you are not
interested in explicitly initializing each element of the array. In
such cases you can use an initializer like: <CODE>{0,}</CODE>, which will
initialize the entire array to <CODE>0</CODE>.
</P><P>
A shortcoming of this implementation is that a variable declared with
<CODE>GLOBALVALUEREF</CODE> or <CODE>GLOBALVALUEDEF</CODE> is always an array. For
example, the declaration:
</P><P>
<TABLE><tr><td>&nbsp;</td><td class=example><pre>GLOBALVALUEREF(int, ijk);
</pre></td></tr></table></P><P>
declares the variable <CODE>ijk</CODE> as an array of type <CODE>int [1]</CODE>.
This is done because a globalvalue is actually a constant; its "value"
is what the linker would normally consider an address. That is not how
an integer value works in C, but it is how an array works. So treating
the symbol as an array name gives consistent results--with the
exception that the value seems to have the wrong type. <STRONG>Don't
try to access an element of the array.</STRONG> It doesn't have any elements.
The array "address" may not be the address of actual storage.
</P><P>
The fact that the symbol is an array may lead to warnings where the
variable is used. Insert type casts to avoid the warnings. Here is an
example; it takes advantage of the ANSI C feature allowing macros that
expand to use the same name as the macro itself.
</P><P>
<TABLE><tr><td>&nbsp;</td><td class=example><pre>GLOBALVALUEREF (int, ss$_normal);
GLOBALVALUEDEF (int, xyzzy,123);
#ifdef __GNUC__
#define ss$_normal ((int) ss$_normal)
#define xyzzy ((int) xyzzy)
#endif
</pre></td></tr></table></P><P>
Don't use <CODE>globaldef</CODE> or <CODE>globalref</CODE> with a variable whose
type is an enumeration type; this is not implemented. Instead, make the
variable an integer, and use a <CODE>globalvaluedef</CODE> for each of the
enumeration values. An example of this would be:
</P><P>
<TABLE><tr><td>&nbsp;</td><td class=example><pre>#ifdef __GNUC__
GLOBALDEF (int, color, 0);
GLOBALVALUEDEF (int, RED, 0);
GLOBALVALUEDEF (int, BLUE, 1);
GLOBALVALUEDEF (int, GREEN, 3);
#else
enum globaldef color {RED, BLUE, GREEN = 3};
#endif
</pre></td></tr></table></P><P>
<A NAME="VMS Misc"></A>
<HR SIZE="6">
<A NAME="SEC145"></A>
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_11.html#SEC144" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_11.html#SEC144"> &lt; </A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_12.html#SEC146" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_12.html#SEC146"> &gt; </A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT"> &nbsp; <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_11.html#SEC142" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_11.html#SEC142"> &lt;&lt; </A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_11.html#SEC142" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_11.html#SEC142"> Up </A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_12.html#SEC146" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_12.html#SEC146"> &gt;&gt; </A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT"> &nbsp; <TD VALIGN="MIDDLE" ALIGN="LEFT"> &nbsp; <TD VALIGN="MIDDLE" ALIGN="LEFT"> &nbsp; <TD VALIGN="MIDDLE" ALIGN="LEFT"> &nbsp; <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc.html#SEC_Top" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc.html#SEC_Top">Top</A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_toc.html#SEC_Contents" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_toc.html#SEC_Contents">Contents</A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_24.html#SEC261" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_24.html#SEC261">Index</A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_abt.html#SEC_About" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_abt.html#SEC_About"> ? </A>]</TD>
</TR></TABLE>
<H2> 11.3 Other VMS Issues </H2>
<!--docid::SEC145::-->
<P>
<A NAME="IDX422"></A>
<A NAME="IDX423"></A>
<A NAME="IDX424"></A>
GCC automatically arranges for <CODE>main</CODE> to return 1 by default if
you fail to specify an explicit return value. This will be interpreted
by VMS as a status code indicating a normal successful completion.
Version 1 of GCC did not provide this default.
</P><P>
GCC on VMS works only with the GNU assembler, GAS. You need version
1.37 or later of GAS in order to produce value debugging information for
the VMS debugger. Use the ordinary VMS linker with the object files
produced by GAS.
</P><P>
<A NAME="IDX425"></A>
<A NAME="IDX426"></A>
Under previous versions of GCC, the generated code would occasionally
give strange results when linked to the sharable <TT>`VAXCRTL'</TT> library.
Now this should work.
</P><P>
A caveat for use of <CODE>const</CODE> global variables: the <CODE>const</CODE>
modifier must be specified in every external declaration of the variable
in all of the source files that use that variable. Otherwise the linker
will issue warnings about conflicting attributes for the variable. Your
program will still work despite the warnings, but the variable will be
placed in writable storage.
</P><P>
<A NAME="IDX427"></A>
<A NAME="IDX428"></A>
<A NAME="IDX429"></A>
Although the VMS linker does distinguish between upper and lower case
letters in global symbols, most VMS compilers convert all such symbols
into upper case and most run-time library routines also have upper case
names. To be able to reliably call such routines, GCC (by means of
the assembler GAS) converts global symbols into upper case like other
VMS compilers. However, since the usual practice in C is to distinguish
case, GCC (via GAS) tries to preserve usual C behavior by augmenting
each name that is not all lower case. This means truncating the name
to at most 23 characters and then adding more characters at the end
which encode the case pattern of those 23. Names which contain at
least one dollar sign are an exception; they are converted directly into
upper case without augmentation.
</P><P>
Name augmentation yields bad results for programs that use precompiled
libraries (such as Xlib) which were generated by another compiler. You
can use the compiler option <SAMP>`/NOCASE_HACK'</SAMP> to inhibit augmentation;
it makes external C functions and variables case-independent as is usual
on VMS. Alternatively, you could write all references to the functions
and variables in such libraries using lower case; this will work on VMS,
but is not portable to other systems. The compiler option <SAMP>`/NAMES'</SAMP>
also provides control over global name handling.
</P><P>
Function and variable names are handled somewhat differently with GNU
C++. The GNU C++ compiler performs <EM>name mangling</EM> on function
names, which means that it adds information to the function name to
describe the data types of the arguments that the function takes. One
result of this is that the name of a function can become very long.
Since the VMS linker only recognizes the first 31 characters in a name,
special action is taken to ensure that each function and variable has a
unique name that can be represented in 31 characters.
</P><P>
If the name (plus a name augmentation, if required) is less than 32
characters in length, then no special action is performed. If the name
is longer than 31 characters, the assembler (GAS) will generate a
hash string based upon the function name, truncate the function name to
23 characters, and append the hash string to the truncated name. If the
<SAMP>`/VERBOSE'</SAMP> compiler option is used, the assembler will print both
the full and truncated names of each symbol that is truncated.
</P><P>
The <SAMP>`/NOCASE_HACK'</SAMP> compiler option should not be used when you are
compiling programs that use libg++. libg++ has several instances of
objects (i.e. <CODE>Filebuf</CODE> and <CODE>filebuf</CODE>) which become
indistinguishable in a case-insensitive environment. This leads to
cases where you need to inhibit augmentation selectively (if you were
using libg++ and Xlib in the same program, for example). There is no
special feature for doing this, but you can get the result by defining a
macro for each mixed case symbol for which you wish to inhibit
augmentation. The macro should expand into the lower case equivalent of
itself. For example:
</P><P>
<TABLE><tr><td>&nbsp;</td><td class=example><pre>#define StuDlyCapS studlycaps
</pre></td></tr></table></P><P>
These macro definitions can be placed in a header file to minimize the
number of changes to your source code.
</P><P>
<A NAME="Portability"></A>
<HR SIZE="6">
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_11.html#SEC142" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_11.html#SEC142"> &lt;&lt; </A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_12.html#SEC146" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_12.html#SEC146"> &gt;&gt; </A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT"> &nbsp; <TD VALIGN="MIDDLE" ALIGN="LEFT"> &nbsp; <TD VALIGN="MIDDLE" ALIGN="LEFT"> &nbsp; <TD VALIGN="MIDDLE" ALIGN="LEFT"> &nbsp; <TD VALIGN="MIDDLE" ALIGN="LEFT"> &nbsp; <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc.html#SEC_Top" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc.html#SEC_Top">Top</A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_toc.html#SEC_Contents" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_toc.html#SEC_Contents">Contents</A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_24.html#SEC261" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_24.html#SEC261">Index</A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_abt.html#SEC_About" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_abt.html#SEC_About"> ? </A>]</TD>
</TR></TABLE>
<BR>
<FONT SIZE="-1">
This document was generated
by <I>GCC Administrator</I> on <I>March, 17 2001</I>
using <A HREF="tppmsgs/msgs0.htm#1" tppabs="http://www.mathematik.uni-kl.de/~obachman/Texi2html"><I>texi2html</I></A>
</BODY>
</HTML>