install-old.texi

GCC

Unix.
@end enumerate

If you wish to use GNU C++ you must first install GNU CC, and then
perform the following steps:

@enumerate
@item
Define the VMS logical name @samp{GNU_GXX_INCLUDE} to point to the
directory where the preprocessor will search for the C++ header files.
This can be done with the command:@refill

@smallexample
$ assign /system /translation=concealed -
  disk:[gcc.gxx_include.] gnu_gxx_include
@end smallexample

@noindent
with the appropriate disk and directory name.  If you are going to be
using a C++ runtime library, this is where its install procedure will install
its header files.

@item
Obtain the file @file{gcc-cc1plus.exe}, and place this in the same
directory that @file{gcc-cc1.exe} is kept.

The GNU C++ compiler can be invoked with a command like @samp{gcc /plus
/verbose file.cc}, which is equivalent to the command @samp{g++ -v -c
file.cc} in Unix.
@end enumerate

We try to put corresponding binaries and sources on the VMS distribution
tape.  But sometimes the binaries will be from an older version than the
sources, because we don't always have time to update them.  (Use the
@samp{/version} option to determine the version number of the binaries and
compare it with the source file @file{version.c} to tell whether this is
so.)  In this case, you should use the binaries you get to recompile the
sources.  If you must recompile, here is how:

@enumerate
@item
Execute the command procedure @file{vmsconfig.com} to set up the files
@file{tm.h}, @file{config.h}, @file{aux-output.c}, and @file{md.}, and
to create files @file{tconfig.h} and @file{hconfig.h}.  This procedure
also creates several linker option files used by @file{make-cc1.com} and
a data file used by @file{make-l2.com}.@refill

@smallexample
$ @@vmsconfig.com
@end smallexample

@item
Setup the logical names and command tables as defined above.  In
addition, define the VMS logical name @samp{GNU_BISON} to point at the
to the directories where the Bison executable is kept.  This should be
done with the command:@refill

@smallexample
$ assign /system /translation=concealed -
  disk:[bison.] gnu_bison
@end smallexample

You may, if you choose, use the @file{INSTALL_BISON.COM} script in the
@file{[BISON]} directory.

@item
Install the @samp{BISON} command with the command line:@refill

@smallexample
$ set command /table=sys$common:[syslib]dcltables -
  /output=sys$common:[syslib]dcltables -
  gnu_bison:[000000]bison
$ install replace sys$common:[syslib]dcltables
@end smallexample

@item
Type @samp{@@make-gcc} to recompile everything (alternatively, submit
the file @file{make-gcc.com} to a batch queue).  If you wish to build
the GNU C++ compiler as well as the GNU CC compiler, you must first edit
@file{make-gcc.com} and follow the instructions that appear in the
comments.@refill

@item
In order to use GCC, you need a library of functions which GCC compiled code
will call to perform certain tasks, and these functions are defined in the
file @file{libgcc2.c}.  To compile this you should use the command procedure
@file{make-l2.com}, which will generate the library @file{libgcc2.olb}.
@file{libgcc2.olb} should be built using the compiler built from
the same distribution that @file{libgcc2.c} came from, and
@file{make-gcc.com} will automatically do all of this for you.

To install the library, use the following commands:@refill

@smallexample
$ library gnu_cc:[000000]gcclib/delete=(new,eprintf)
$ library gnu_cc:[000000]gcclib/delete=L_*
$ library libgcc2/extract=*/output=libgcc2.obj
$ library gnu_cc:[000000]gcclib libgcc2.obj
@end smallexample

The first command simply removes old modules that will be replaced with
modules from @file{libgcc2} under different module names.  The modules
@code{new} and @code{eprintf} may not actually be present in your
@file{gcclib.olb}---if the VMS librarian complains about those modules
not being present, simply ignore the message and continue on with the
next command.  The second command removes the modules that came from the
previous version of the library @file{libgcc2.c}.

Whenever you update the compiler on your system, you should also update the
library with the above procedure.

@item
You may wish to build GCC in such a way that no files are written to the
directory where the source files reside.  An example would be the when
the source files are on a read-only disk.  In these cases, execute the
following DCL commands (substituting your actual path names):

@smallexample
$ assign dua0:[gcc.build_dir.]/translation=concealed, -
         dua1:[gcc.source_dir.]/translation=concealed  gcc_build
$ set default gcc_build:[000000]
@end smallexample

@noindent
where the directory @file{dua1:[gcc.source_dir]} contains the source
code, and the directory @file{dua0:[gcc.build_dir]} is meant to contain
all of the generated object files and executables.  Once you have done
this, you can proceed building GCC as described above.  (Keep in mind
that @file{gcc_build} is a rooted logical name, and thus the device
names in each element of the search list must be an actual physical
device name rather than another rooted logical name).

@item
@strong{If you are building GNU CC with a previous version of GNU CC,
you also should check to see that you have the newest version of the
assembler}.  In particular, GNU CC version 2 treats global constant
variables slightly differently from GNU CC version 1, and GAS version
1.38.1 does not have the patches required to work with GCC version 2.
If you use GAS 1.38.1, then @code{extern const} variables will not have
the read-only bit set, and the linker will generate warning messages
about mismatched psect attributes for these variables.  These warning
messages are merely a nuisance, and can safely be ignored.

If you are compiling with a version of GNU CC older than 1.33, specify
@samp{/DEFINE=("inline=")} as an option in all the compilations.  This
requires editing all the @code{gcc} commands in @file{make-cc1.com}.
(The older versions had problems supporting @code{inline}.)  Once you
have a working 1.33 or newer GNU CC, you can change this file back.

@item
If you want to build GNU CC with the VAX C compiler, you will need to
make minor changes in @file{make-cccp.com} and @file{make-cc1.com}
to choose alternate definitions of @code{CC}, @code{CFLAGS}, and
@code{LIBS}.  See comments in those files.  However, you must
also have a working version of the GNU assembler (GNU as, aka GAS) as
it is used as the back-end for GNU CC to produce binary object modules
and is not included in the GNU CC sources.  GAS is also needed to
compile @file{libgcc2} in order to build @file{gcclib} (see above);
@file{make-l2.com} expects to be able to find it operational in
@file{gnu_cc:[000000]gnu-as.exe}.

To use GNU CC on VMS, you need the VMS driver programs
@file{gcc.exe}, @file{gcc.com}, and @file{gcc.cld}.  They are
distributed with the VMS binaries (@file{gcc-vms}) rather than the
GNU CC sources.  GAS is also included in @file{gcc-vms}, as is Bison.

Once you have successfully built GNU CC with VAX C, you should use the
resulting compiler to rebuild itself.  Before doing this, be sure to
restore the @code{CC}, @code{CFLAGS}, and @code{LIBS} definitions in
@file{make-cccp.com} and @file{make-cc1.com}.  The second generation
compiler will be able to take advantage of many optimizations that must
be suppressed when building with other compilers.
@end enumerate

Under previous versions of GNU CC, the generated code would occasionally
give strange results when linked with the sharable @file{VAXCRTL} library.
Now this should work.

Even with this version, however, GNU CC itself should not be linked with
the sharable @file{VAXCRTL}.  The version of @code{qsort} in
@file{VAXCRTL} has a bug (known to be present in VMS versions V4.6
through V5.5) which causes the compiler to fail.

The executables are generated by @file{make-cc1.com} and
@file{make-cccp.com} use the object library version of @file{VAXCRTL} in
order to make use of the @code{qsort} routine in @file{gcclib.olb}.  If
you wish to link the compiler executables with the shareable image
version of @file{VAXCRTL}, you should edit the file @file{tm.h} (created
by @file{vmsconfig.com}) to define the macro @code{QSORT_WORKAROUND}.

@code{QSORT_WORKAROUND} is always defined when GNU CC is compiled with
VAX C, to avoid a problem in case @file{gcclib.olb} is not yet
available.

@node Collect2
@section @code{collect2}

GNU CC uses a utility called @code{collect2} on nearly all systems to arrange
to call various initialization functions at start time.

The program @code{collect2} works by linking the program once and
looking through the linker output file for symbols with particular names
indicating they are constructor functions.  If it finds any, it
creates a new temporary @samp{.c} file containing a table of them,
compiles it, and links the program a second time including that file.

@findex __main
@cindex constructors, automatic calls
The actual calls to the constructors are carried out by a subroutine
called @code{__main}, which is called (automatically) at the beginning
of the body of @code{main} (provided @code{main} was compiled with GNU
CC).  Calling @code{__main} is necessary, even when compiling C code, to
allow linking C and C++ object code together.  (If you use
@option{-nostdlib}, you get an unresolved reference to @code{__main},
since it's defined in the standard GCC library.  Include @option{-lgcc} at
the end of your compiler command line to resolve this reference.)

The program @code{collect2} is installed as @code{ld} in the directory
where the passes of the compiler are installed.  When @code{collect2}
needs to find the @emph{real} @code{ld}, it tries the following file
names:

@itemize @bullet
@item
@file{real-ld} in the directories listed in the compiler's search
directories.

@item
@file{real-ld} in the directories listed in the environment variable
@code{PATH}.

@item
The file specified in the @code{REAL_LD_FILE_NAME} configuration macro,
if specified.

@item
@file{ld} in the compiler's search directories, except that
@code{collect2} will not execute itself recursively.

@item
@file{ld} in @code{PATH}.
@end itemize

``The compiler's search directories'' means all the directories where
@code{gcc} searches for passes of the compiler.  This includes
directories that you specify with @option{-B}.

Cross-compilers search a little differently:

@itemize @bullet
@item
@file{real-ld} in the compiler's search directories.

@item
@file{@var{target}-real-ld} in @code{PATH}.

@item
The file specified in the @code{REAL_LD_FILE_NAME} configuration macro,
if specified.

@item
@file{ld} in the compiler's search directories.

@item
@file{@var{target}-ld} in @code{PATH}.
@end itemize

@code{collect2} explicitly avoids running @code{ld} using the file name
under which @code{collect2} itself was invoked.  In fact, it remembers
up a list of such names---in case one copy of @code{collect2} finds
another copy (or version) of @code{collect2} installed as @code{ld} in a
second place in the search path.

@code{collect2} searches for the utilities @code{nm} and @code{strip}
using the same algorithm as above for @code{ld}.

@node Header Dirs
@section Standard Header File Directories

@code{GCC_INCLUDE_DIR} means the same thing for native and cross.  It is
where GNU CC stores its private include files, and also where GNU CC
stores the fixed include files.  A cross compiled GNU CC runs
@code{fixincludes} on the header files in @file{$(tooldir)/include}.
(If the cross compilation header files need to be fixed, they must be
installed before GNU CC is built.  If the cross compilation header files
are already suitable for ISO C and GNU CC, nothing special need be
done).

@code{GPLUSPLUS_INCLUDE_DIR} means the same thing for native and cross.  It
is where @code{g++} looks first for header files.  The C++ library
installs only target independent header files in that directory.

@code{LOCAL_INCLUDE_DIR} is used only for a native compiler.  It is
normally @file{/usr/local/include}.  GNU CC searches this directory so
that users can install header files in @file{/usr/local/include}.

@code{CROSS_INCLUDE_DIR} is used only for a cross compiler.  GNU CC
doesn't install anything there.

@code{TOOL_INCLUDE_DIR} is used for both native and cross compilers.  It
is the place for other packages to install header files that GNU CC will
use.  For a cross-compiler, this is the equivalent of
@file{/usr/include}.  When you build a cross-compiler,
@code{fixincludes} processes any header files in this directory.