To compile the OCEAN sources, proceed as follows: * FIRST READ THIS ENTIRE INSTALLATION MANUAL * READ ALSO THE FILE donau.et.tudelft.nl:pub/ocean/INSTALLATION * Get the files donau.et.tudelft.nl:pub/ftp/ocean/ocean_src/*.tar.gz * Destinate a directory as the "home" of the ocean system, e.g. /users/ocean. Set the environment variable: % setenv OCEANPATH /users/ocean % cd $OCEANPATH * unpack each file as follows: % gzip -dc file.tar.gz | tar xf - This creates source directories in $OCEANPATH/src. * set the environment variable MACHINE to something sensible. This environment variable determines the names of the machine-dependent subdirectories in $OCEANPATH/{bin,lib,celllibs}. For example, if you type "setenv MACHINE vax" then the directories bin/vax, lib/vax etc. will be created and used during the compilation and installation process. You may want to set MACHINE to the output of bin/thearch: % setenv MACHINE `sh $OCEANPATH/src/scripts/thearch` * The programs nelsea, seadali, blif2sls and esea require CACD libraries. These are available from donau.et.tudelft.nl:/pub/ocean/cacd_src.tar. Compile these libs before attempting to compile ocean. While compiling ocean, make sure your CACD libraries and includes can be found by setting the environent ICDPATH to the root directory of the CACD tree: % setenv ICDPATH /home/neuzelaar/cacd Alternatively, specify the CACD home with the -i option to buildsrc. * Start the compilation process: % cd $OCEANPATH; % sh src/scripts/buildsrc -c If a program fails to compile, fix the problem, and then type: % cd $OCEANPATH; % sh bin/buildsrc -cp This builds libraries and executables in $OCEANPATH/lib/$MACHINE and $OCEANPATH/bin/$MACHINE and include files in $OCEANPATH/include. Some tools also install manual pages in $OCEANPATH/man. * You need InterViews 3.1 to build $OCEANPATH/src/cruise. If you don't have InterViews-3.1 just edit src/buildsrc and remove cruise from the DEFAULT_PROGRAMS list. Actually, you may live very happily without cruise. * If you use the GNU compiler prior to version 2.7.2, you need a little trick. The problem is that older versions of gcc have a bug that causes it to ignore user-defined type casts to a reference to something. Our solution is to use a csh-script that recognizes the ocean source files that contain such type casts. The script calls a sed process to patch the source on-the-fly, before passing the source file to the GNU g++ compiler. We install the script named "g++" in a directory that comes early in the search PATH, in any case before the directory that contains the real g++. To avoid confusion, it always prints a line to stdout that warns you that you are calling the csh-script named "g++". You can find a copy of the script on donau.et.tudelft.nl:pub/ocean/ocean_src in the file "g++". Copy it to a directory that comes early in your search PATH and chmod +x it. Then execute "buildsrc" to compile the ocean sources. You may need to edit the g++ script a bit, e.g. to change the absolute path to the location where your GNU g++ executable lives. FYI: we succesfully compiled OCEAN with gcc-2.4.5 on PA-RISC1.1 machines and with gcc-2.5.8 on a Sun sparc station 10 running SunOS 4.1.3. Other versions may or may not work. We noticed that SunOS-4 releases lack a lot of function prototypes in /usr/include/*.h. Actually, SunOS-4 is long way from being ANSI compliant as far as the C interface goes. It's a very bad program development environment, this SunOS-4 thing. If you experience mysterious core dumps on Linux, especially in the programs "gnarp", "seedif" and others, you have probably hit a common gcc-2.7.2 installation problem. The trick is to call GNU c++ instead of GNU g++. This c++ thing only links with libstdc++.a whereas the g++ installations that we have come across tried to link to both libstdc++.a and libg++.a, which either gives you lots of linker errors (HP) or does not give any error messages but makes the Ocean programs crash in mysterious ways (Linux). * Complaints, trouble reports and praise to ocean@donau.et.tudelft.nl