This section describes the following, general platform-related issues:
Rational ClearCase is implemented through a set of shared libraries. In addition, three shared libraries are supplied from vendors in ccase-home-dir/shlib (where ccase-home-dir is your installation directory, /opt/rational/clearcase by default). The libraries are the C++ compiler library libC.so or libC.sl (depending on vendor; other possible shared C compiler library names follow the pattern libCstring.so, where string may be any short character string), the Galaxy run-time library libvgalaxy++.so (or libvgalaxy++.sl, depending on vendor), and the EZ-RPC run-time library libezrpc.so (.sl).
Note that the SGI IRIX and Linux for IBM/390 platforms do not provide Galaxy libraries in /opt/rational/clearcase/shlib. The AIX, HP-UX/IPF, and Linux for x86 platforms do provide the Galaxy libraries.
If, for any reason, the ClearCase libraries in the ccase-home-dir/shlib directory are missing, the ClearCase executables do not run.
If you install Rational ClearCase in a nondefault location (that is, other than in /opt/rational/clearcase), you must set the proper platform-dependent library search-path environment variable to include the ccase-home-dir/shlib pathname so that ClearCase executables can find the required ClearCase shared libraries and vendor-supplied libraries.
The order of the pathnames in the environment variable is important. At run time, ClearCase must find the three supplied vendor libraries before it finds any other versions of those libraries in other paths in the list. Other applications that use this definition of the library search-path environment variable may find these supplied vendor libraries instead of other versions of those libraries installed on your system. This behavior may or may not be compatible with those applications.
If the supplied vendor libraries are missing, the executables may search the system libraries (the order of search, where it searches, and whether it searches is platform dependent). If a library of the appropriate name is found, the execution may not succeed because the library found may not be compatible with the ClearCase executable.
The following table indicates the search-path environment variable that you need to define on each supported UNIX platform so that you can access the ClearCase shared libraries. To find the architecture mnemonic associated with your platform, see the sections dealing with individual platforms.
|
Architecture Mnemonic
|
Search-Path Environment-Variable Names
|
|---|---|
|
sun5
|
LD_LIBRARY_PATH
|
|
sgi6
|
LD_LIBRARY64_PATH
|
|
rhat_x86, linux_s390
|
LD_LIBRARY_PATH
|
|
hp11_pa, hp11_ia64
|
SHLIB_PATH
|
|
aix4_power1
|
LIBPATH
|
1Note that on AIX, if LIBPATH contains any pathnames, it must also include ccase-home-dir/shlib.
When running clearmake, you can invoke compatibility modes to incorporate features of make programs native to some UNIX platforms. For more information, see Building Software.
Some platforms continue to provide Cfront-based compilers. If you are using such a compiler, you may find detailed information about the best way to use it with ClearCase in Building Software. In general, it is recommended that you use a compiler that supports the ANSI C++ explicit instantiation syntax for best results.
ClearCase is a client/server application. Developers use client hosts to run the client programs that constitute the user-level interface to ClearCase. ClearCase data (for example, VOB storage directories and view storage directories) reside on server hosts. ClearCase server processes run on server hosts, communicating with client programs through remote procedure calls (RPCs).
For descriptions of the installation models and of the requirements for ClearCase server hosts and client hosts, see the Installation Guide.
All UNIX platforms that ClearCase supports can act as registry, license, or view servers. A typical developer’s workstation is both a client host (because the developer runs ClearCase on it) and a server host (because the developer’s views reside there).
All UNIX platforms that ClearCase supports can also act as VOB servers. However, the ability to act as a VOB server in a heterogeneous environment may have some platform dependencies. To ensure that any computer on which you are planning to host a VOB can act as a VOB server to all its intended clients, see the sections on individual UNIX platforms.
For details about using UNIX systems as ClearCase servers in a Windows/UNIX environment, see the Administrator’s Guide.
On some UNIX systems, ClearCase GUI programs added in Release 3.0.x are not supported or have restricted support:
These ClearCase GUI issues are related to restricted support for the Release 3.0.x interfaces:
Support for the ClearCase Merge Manager includes a new program, cleardescribe. This program is not the same as the graphical command by that name on platforms supporting the Release 3.0.x GUIs. Rather, it is similar to cleartool describe, except that it provides a restricted set of options. The syntax for the cleardescribe command is as follows:
cleardescribe { object-selector | pname } ...
There is no change in support for xclearcase and xcleardiff.
The Merge Manager relies on data provided by cleartool describe to get information necessary for a merge. On platforms that support the 3.0.x GUI programs, it displays this data using the Properties Browser GUIs.
IRIX, HP-UX/IPF, and Linux for IBM S/390 and zSeries systems do not support these GUIs. Instead, an xterm displays the output of the cleartool describe command.
Note: If the user tries to resize the window before seeing the prompt Type <CR> to exit, some of the data displayed in the window may be duplicated. This problem occurs because of the behavior of more(1).
Warning: On some UNIX systems (for example, HP and Solaris), tar(1) sets file access times to the current time when it is run, which can interfere with derived object (DO) and cleartext storage pool scrubbing patterns. For example, a nightly tar operation backs up DO pools. The scrubber utility, by default, scrubs only DOs not accessed in four days (96 hours). Because DOs from the backed-up pools never appear to be more than one day old, they are never scrubbed. For more information about backup procedures, see the Administrator’s Guide.