Building G++ 1.37.1 for the Apollo 4-May-90 John Vasta These changes enable G++ 1.37.1 to be used on Apollo SR10.2 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.37.1 built and installed; parts of it are used in G++ and it's used to compile G++. 2. Get the g++-1.37.1 distribution and set it up (you should have a g++-1.37.1 directory). This may require finding the g++-1.37.0 distribution and applying a patch kit to bring it up to 1.37.1). 3. If you got the tar file containing my changes, then you got complete replacements for the following files: g++-1.37.1/Makefile g++-1.37.1/collect.c g++-1.37.1/config.g++ g++-1.37.1/cplus-class.c g++-1.37.1/cplus-dem.c g++-1.37.1/cplus-init.c g++-1.37.1/cplus-lex.c g++-1.37.1/cplus-parse.y g++-1.37.1/cplus-tab.c g++-1.37.1/cplus-tab.h g++-1.37.1/expr.c g++-1.37.1/gcc.c g++-1.37.1/gnulib3.c g++-1.37.1/stmt.c If you unpacked the tar file in the directory containing the g++-1.37.1 directory, then the files were overlaid and you're all set. Otherwise you'll need to move the files into the correct places. If you got the shar file containing diffs, then you should have unpacked it to get these files: APOLLO-G++-README apollo-g++-1.37.1.diffs Patch the files in g++-1.37.1 using apollo-g++-1.37.1.diffs 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.37.1, then do this: cd /usr/local/gnu patch -p 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