/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/ocs
or/usr/ocs
as the installation place (at least, a symbolic link from there to the installation place must exist). Otherwise, it will become necessary to defineLD_LIBRARY_PATH
to point to ocs/lib/sol2-sparc
for running applications which are linked against Opal libraries which do indirectly base on other ones in the distribution (currently onlyOPAL_WIN
andOPAL_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.