4.2 Installing the Programmers Version

Read over the instructions for installing the end-user's version first. This assumes that you have unloaded the `pdp++_version_src.tar.gz' file in something like `/usr/local/pdp++'.

IMPORTANT: Whenever you are compiling, you need to have the environmental variable CPU set to reflect your machine type (see above). Other machine types can be found in the interviews `config/InterViews/arch.def' directory. These are (in addition to the above): VAX, MIPSEL, SUN3, SUN4, SUNi386, SUN, HP300, HP200, HP500, HP, ATT, APOLLO, SONY68, SONYmips, SONY, PEGASUS, M4330, MACII, CRAY, STELLAR, IBMi386, IBMrt, IBMaix, IBMr2, LINUX, LUNA68, LUNA88, MIPSEB, MOTOROLA, X386, DGUX, CONVEX, stratus, ALPHA.

There are a couple of other libraries that the PDP++ software depends on. These need to be made before PDP++ itself can be compiled. Please ensure that all of the following are installed properly:

1) The `readline' library, which will have already been installed if `gdb' or perhaps other gnu programs have been installed on your system. Look for `/usr/local/lib/libreadline.a'. If it isn't there, then download a version of it from one of the gnu ftp server sites (e.g., prep.ai.mit.edu), and compile and install the library.

2) The `libiberty' library (because `readline' depends on it). Again, this can be found in the `gdb' or `binutils' distributions from gnu ftp sites. If you are using `g++', then you can include all of the `libiberty.a' library. However, if you are not using `g++' to compile the software, there are only two files that are needed from the gnu `libiberty' library (and the other files actually conflict with the standard libraries for these compilers). These two files, `alloca.o' and `xmalloc.o' can be copied from the directory where libiberty was compiled. These are copied into the `lib/myiberty_CPU' directory (where CPU is your CPU type as described above). Note that object files for SUN4, HP800, and SGI are already provided in the distribution. These are then made into the `libmyiberty.a' library. The decision of which iberty library to use is made by the IBERTY_LIB variable in the makefiles (described below).

3) If using g++, you need to make the `libiostream.a' and probably the `libstdc++.a' library in the libg++ distribution. It seems that in the latest distribution of libg++ both of these are installed in `/usr/local/lib' automatically, but if they are not there, `libiostream.a' is made in the `libio' directory in the libg++ distribution (do a make install to get the properly installed or copy it yourself), and `libstdc++.a' is made in the `libstdc++.a' directory. CC/cfront users should have their iostream code linked in automatically via the standard C++ library that comes with the compiler.

4) Install the InterViews library, which provides the graphics toolkit used by PDP++. Unfortunately, due to limitations in the way classes were declared with private members, it was necessary to modify the InterViews code directly, instead of simply providing some overloaded classes which fix some bugs. Thus, we have a patch kit that can be applied to the InterViews 3.2a distribution, which can be obtained from `sgi.com' anonymous ftp in the `graphics/interviews' directory. These patches, and some miscellaneous information about interviews can be found in the `PDPDIR/lib/interviews' directory. Read the `README' file in that directory for more information about how to patch and compile an interviews library that will work with PDP++.

An alternative to compiling interviews yourself is to download pre-compiled interviews libraries from us. These are available for both cfront-based compilers (CC) and for the latest version of the g++ complier (g++) for the same set of machines for which the binary distribution is supported (LINUX, IBMaix, SUN4, HP800, SGI). They can be found in our anonymous ftp site as `pdp++_version_ivlib_CPU_CC.tar.gz' for the cfront (CC) compiler and `..._g++.tar.gz' for g++. The include files, which are necessary to use the libraries to compile PDP++, are in `pdp++_version_ivinc.tar.gz'. These create a directory called `interviews' when extracted, which means this should be done in the `/usr/local' directory so that the interviews directory is `/usr/local/interviews'. Alternatively, these can be installed elsewhere and the IDIRS_EXTRA and LDIRS_EXTRA makefile variables set to point to this directory (see below).

5) Once you have the above libraries installed, the next step is to configure the makefiles for the type of compiler and system you have. These makefiles are located in `PDPDIR/config'. The actual makefiles in a given directory (e.g., `src/bp/Makefile' and `src/bp/CPU/Makefile') are made by combining several makefile components. `config/Makefile.std' has the standard rules for making various things, `config/Makefile.defs' has the standard definitions for everything, and then `config/Makefile.CPU' overrides any of these definitions that need to be set differently for a different CPU type (i.e., "local" definitions). There are several sub-steps to this process as labeled with letters below:

a) If you have installed the software in a location other than `/usr/local/pdp++': You need to change the definition of PDPDIR in both the top-level Makefile (`PDPDIR/Makefile') and in the definitions makefile `PDPDIR/config/Makefile.defs'.

The C++ compiler types that are supported are gnu g++ 2.7.1 or later (labeled with the `g++' extention), and cfront-based system compilers version 3.0 or later (labeled with the `CC' extension). There are makefiles in `PDPDIR/config' for the supported CPU types listed above, and the two different supported compilers. The makefiles are named `Makefile.CPU.cmplr', where cmplr is either `g++' or `CC'. The actual makefile used during compiling for a given machine is the one called `Makefile.CPU', where CPU is the type of system you are compiling on (e.g., SUN4, HP800, SGI, etc.). If you are compiling on a machine for which a standard makefile does not exist, copy one from a supported machine for the same type of compiler. Also, see the notes below about porting to a new type of machine.

b) Copy the appropriate `Makefile.CPU.cmplr' makefile (where cmplr is either g++ or CC depending on which compiler you are using), to `Makefile.CPU' (again, CPU is your machine type, not 'CPU'). For some architectures there is just one `Makefile.CPU' since only one type of compilier is currently supported. In this case you can just leave it as is.

c) You should put any specific "local" definitions or modifications to the makefiles in the `config/Makefile.CPU'. This will be included last in the actual makefiles, and any definitions appearing here will override the standard definitions. To see the various definitions that might affect compiling, look at `Makefile.defs', which contains all the "standard" definitions, along with descriptive comments. The following are items that you will typically have to pay attention to:

i) IOS_INCLUDES and IOS_LIB: In order to be able to access via the CSS script language the functions associated with the standard C++ iostream classes, the type-scanning program `maketa' needs to process the iostream header files: `streambuf.h', `iostream.h', `fstream.h', and `strstream.h'. These files are scanned in the `src/ta' directory, as part of the building of the type access library `libtypea.a'. These header files are different depending on the compiler being used. For CC (cfront) compilers, the IOS_INCLUDES variable should be set to CC-3.1.

These header files are typically located in `/usr/include/CC', which is where the CC-3.1 versions of these files in `src/ta' point to via symbolic links. Thus, if your headers are located elsewhere, you will need to change these symbolic links, or just copy the header files directly into the `ios-CC-3.1' subdirectory in `src/ta'. For g++ users, IOS_INCLUDES variable should be set to g++-2.7.1, corresponding to the latest (2.7.1) version of the iostream files which are already included in the PDP++ distribution, in the subdirectory `ios-g++-2.7.1'. If you upgrade g++ at a later date and wish to recompile pdp++, you can just copy the new iostream files into ios-g++-X.X.X, and set the IOS_INCLUDES variable to g++-X.X.X in the `Makefile.CPU'

Note that you can use the make force_ta action to force a re-scan of the header files. A make optLib is then neccessary to compile this type information into the library. Finally, the IOS_LIB variable needs to be set to -liostream for g++ users, and should be blank for CC users, who will automatically link the standard C++ library containing the iostream code.

ii) IBERTY_LIB this is the name of the libiberty.a library to link, which is -lmyiberty for CC (cfront) users and the default of -liberty for g++ users.

iii) IDIRS_EXTRA and LDIRS_EXTRA can be used to specify locations for other include and library files, respectively (for example, the cfront compiler may need to be told to look in -I/usr/include/CC for include files). Use these if you have installed any libraries (e.g., InterViews) in a non-standard location.

iv) cppC: this is the c-pre-processor, which is usually fairly broken on most machine-specific compilers. Thus, the default is to use the gnu `cccp' compiler, which is assumed to have been installed in `/usr/local/bin/cccp'. This definition is used in the invocation of the `maketa' type scanning program. Note that make install of gcc/g++ does not apparently install this program by default, so you have to manually copy it from either your gcc compile directory or `/usr/lib/gcc-lib/<machine>/cpp'.

v) VT_xxx and TI_xxx: these specify the virtual-table instantiation and template-instantiation (respectively) files, which are needed by different compilers. CC (cfront) requires the VT_xxx files along with the +e[01] flags to only make one copy of virtual tables, while g++ requires the TI_xxx files to only make one copy of the templates.

vi) Porting to a non-supported machine: There are a small set of system-dependent definitions contained in `src/ta/ta_stdef.h', which are triggered by defines set up in the makefiles. NO_BUILTIN_BOOL should be defined if the c++ compiler does not have a bulitin bool type, which is the case with most cfront-based CC compilers, but not g++. CONST_48_ARGS determines if the seed48 and lcong48 functions take const arguments or not. In addition, different platforms may require different defines than those that are flagged in `ta_stdef.h'. In this case, you will have to edit `ta_stdef.h' directly. Please send any such additions, and the corresponding `config/Makefile.CPU' along with any notes to us (`pdpadmin@crab.psy.cmu.edu') so we can put them on our web page for others to use, and incorporate them into subsequent releases.

vii) For some more information about the makefiles, see section 6.1 Makefiles and Directory Organization.

6) The standard makefiles use gnu's `bison' instead of `yacc' for making parsers. If you don't touch any of the .y files in the distribution, you won't need either. If you plan on messing around with the guts of the maketa type scanner or CSS, then you will probably want to install the latest version of `bison'.

7) The dependency information, which is essential if you are going to be editing the main body of PDP++ code, but not necessary for a one-pass make of the system, is not made by the default make world action. If you want to make this dependency information, do it with a make depend after a successful make world. Also, note that the automatic dependencies are made by calling `gcc' in the standard configuration. If your local C compiler supports the -M flag for generating dependency information, then this can be used instead. Just change the definition for CC in your `Makefile.CPU'. If you don't have gcc and your local C compiler doesn't support this, you can edit the end of the `Makefile.std' and change it to use the `makedepend' program, which we have not found to work as well, but it is an option.

8) On some systems, the standard `make' program is broken and will not work with our complex makfile system. This is true of the SUN4 system and IBMaix, and may be true of others. In this case, you will have to install the GNU make program, and use it to compile the software. If you get inexplicable errors about not being able to make certain things (seems to be the .d dependency files in particular that cause a problem), then try using GNU make.

9) If your CPU supports shared libraries (LINUX, IBMaix, HP800, SGI), you will need to insure that the LD_LIBRARY_PATH environment variable includes the path PDPDIR/lib/CPU nad PDPDIR/interviews/LIB/CPU where PDPDIR is the location of the pdp++ distribution, and CPU is your system type as described above.

After setting appropriate definitions, go back up to the PDPDIR and just do a:

make world

this should compile everything. This will make makefiles in each directory based on your CPU type, and then compile the various libraries and then the executables.

Most likely, the make will at least proceed past all the basic directory initialization stuff that is part of `make world'. Thus, if the compile stops after making the makefiles and after making the `maketa' program, you can fix the problem and re-start it by doing `make all' instead of `make world'.

If you run into difficulties during the compile process, the programming guide might contain some useful information for debugging what is going wrong: section 6 Programming with TypeAccess.