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