/usr/ocs or /usr/local/ocs). Do
cp for this purpose; if you
need to move across file-system boundaries, use tar
(or unpack the distribution again in the other file system).
Note: on Solaris, it is currently necessary to use either/usr/local/ocsor/usr/ocsas the installation place (at least, a symbolic link from there to the installation place must exist). Otherwise, it will become necessary to defineLD_LIBRARY_PATHto point to ocs/lib/sol2-sparcfor running applications which are linked against Opal libraries which do indirectly base on other ones in the distribution (currently onlyOPAL_WINandOPAL_READLINE).
/usr/ocs/bin. Afterwards, the command ocs
info should yield
$ ocs info
-> You are using `ocs-2.3a'
-> located at `/usr/ocs'.
-> The project ($OCSPROJECT) is not specified.
Note that it's not possible to call ocs with an
explicite absolute path; it must be found via the search path.
/usr/ocs/lib/emacs/README.emacs.
OCS depends on a large amount of Unix commands, which are listed
together with their absolute locations in
/usr/ocs/lib/om/specs/Specs.basic. We have tried to use
canonical pathes - whatever canonical means under Unix systems. The
reference installation for the Linux version was Redhat 4.2 and for
the Sparc version Solaris 2.5 (SunOS 5.5).
Typically, on Solaris the GNU tools (gcc and gmake) may be installed
at different places as defined in Specs.basic.
If Specs.basic is changed, you need to make
the changes manually also to ShSpecs.basic, or
to run
/usr/ocs/lib/om/etc/gmake2h < Specs.basic > ShSpecs.basic # sh
This should not happen on Solaris systems, since the code of non-standard
features (such as Tcl/Tk and Readline) is included in the
distribution. On Linux, it is expected that -lreadline, -ltcl, and
-ltk are available as shared objects in the standard run path.
Use ldd (ldd -s on Solaris) to analyze, and
perhaps LD_LIBRARY_PATH or ldconfig to fix
problems with shared libraries.