		  Building G++ 1.37.1 for the Apollo
			       4-May-90
			      John Vasta

		Changes for g++-1.39.1 by Christos Zoulas
			christos@ee.cornell.edu


These changes enable G++ 1.39.1 to be used on Apollo SR10.x systems
with some restrictions:

  1. There is no debug information at all (although DDE lets you debug
     in assembly language).

  2. The compiler generates code which is link-compatible with the
     Apollo C compiler and libraries. The GNU assembler was hacked to
     produce COFF output modules. In order to use the Apollo global
     libraries, the code sections are actually put into writable data
     sections, so that the loader can relocate them (GCC doesn't
     generate code which needs no relocation, like the Apollo
     compilers). This means that program text cannot be shared, and
     loading may take slightly longer, but I don't think it will be
     noticable.


The following prerequisites are required:

  1. Running SR10.2 or later and using version 6.7 or later of the
     Apollo C compiler (it may work on earlier SR10 releases and C
     compilers, but I haven't tried it).

  2. Running in a bsd4.3 environment in order to build the GNU
     software (although the resulting binaries will work in any
     environment).

  3. Already have GCC 1.37.1 up and running (you'll need to get my GCC
     changes from the same place you got this stuff from).

  4. Virgin distribution of G++ 1.37.1 (available via anonymous ftp
     from prep.ai.mit.edu in the /pub/gnu directory, as well as from
     other sites. On prep, at least, it looks like you have to get the
     g++-1.37.0 distribution and then the g++.diff-1.37.0-1.37.1 patch
     kit).


Here are the steps to follow:

  1. First get GCC 1.40 built and installed; parts of it are used in
     G++ and it's used to compile G++.

  2. Get the g++-1.39.1 distribution and set it up (you should have a
     g++-1.39.1 directory). 

  3. If you got the tar file containing my changes, then you got
     context diffs for the following files:

	g++-1.39.1-diff/Makefile.diff
	g++-1.39.1-diff/collect.c.diff
	g++-1.39.1-diff/config.g++.diff
	g++-1.39.1-diff/cplus-class.c.diff
	g++-1.39.1-diff/cplus-dem.c.diff
	g++-1.39.1-diff/cplus-except.c.diff
	g++-1.39.1-diff/cplus-lex.c.diff
	g++-1.39.1-diff/cplus-parse.y.diff
	g++-1.39.1-diff/expr.c.diff
	g++-1.39.1-diff/gcc.c.diff
	g++-1.39.1-diff/gnulib3.c.diff
	g++-1.39.1-diff/stmt.c.diff

     Patch the files in g++-1.39.1 using the diff files as
     the input to the /usr/new/patch utility. NOTE: you should use the
     -p option with patch so that it patches files in subdirectories,
     and do the patching from the directory containing the libg++
     directory. For example, if you have the directory
     /usr/local/gnu/g++-1.39.1, then do this:

	cd /usr/local/gnu
	patch -p < diff-file


  4. If you are running SR10.3 or later then you can arrange for G++
     programs to automatically call class destructor functions for
     static objects when they terminate. If you do not have SR10.3
     yet, then you'll have to explicitly use `exit()' to return from
     your main program. To enable the automatic destructor functions
     for SR10.3 and later, uncomment the -DHAVE_ATEXIT flag in the
     COFFLAGS macro definition in the Makefile.

  5. Build G++:

	Make sure the g++ files have been updated

	G++ uses several modules from the gcc directory. G++ is
	compiled with gcc, and gcc needs to be compiled with itself so
	that the gcc modules are compatible with the g++ modules. If
	you tested the gcc build by bootstrapping it then the .o
	files left in the gcc directory are gcc-compiled.  Otherwise,
	you can build gcc with itself by making sure that gcc is
	installed, then going into the gcc directory and executing

	    make clean
	    make CC=gcc CFLAGS=-O

	Then set up the g++->gcc links by going back into the g++
	directory and executing 'make maketest'

	Create configuration links by running the config.g++ script
	with the argument 'apollo68' (i.e. `config.g++ apollo68')

	Run 'make'

	Install it with 'make install'

Notes:

  o There are some known problems with G++ on the Apollo at this
    point.  One problem is that functions which take `char' or `short'
    arguments cannot be inlined - G++ either generates bad code to
    access those arguments, or it aborts during compilation.

  o I added rules to the Makefile to build a dummy version of libg++.a
    so that the startup function `__main()' is available without
    having to build all of libg++. This gets installed in
    /usr/local/lib. You can later replace it with the real version of
    libg++.a.

  o A configuration change I made in the g++ command driver is to have
    it automatically include "/usr/local/lib/libg++.a" when linking
    programs, instead of just using "-lg++". Since the Apollo linker
    doesn't look in /usr/local/lib by default, you would have to use
    "-L/usr/local/lib" on every g++ link command if you just use
    "-lg++". My change to gcc.c makes it automatically prefix the
    value of the STANDARD_STARTFILE_PREFIX macro to "libg++.a".

  o As noted above, unless you're running SR10.3 or later you won't
    get automatic execution of destructors for static objects; you
    have to explicitly call the `exit()' function. This is due to the
    way exit() gets called in the Apollo environment; the call is not
    in crt0.o, but in a global library. Therefore, if a new version of
    exit() is bound into a program, it won't be called because the
    call to exit() from the global library has already been bound and
    is unaffected. Only if the program calls exit() itself will the
    new version be called. At SR10.3 and beyond the ANSI C `atexit()'
    facility is supported, so it is used to register the destructor
    execution routine.


John Vasta                Hewlett-Packard Apollo Systems Division
vasta@apollo.hp.com       M.S. CHA-01-LT
(508) 256-6600 x6362      300 Apollo Drive, Chelmsford, MA 01824
UUCP: {decwrl!decvax, mit-eddie, attunix}!apollo!vasta
