Sites with hardware for which object code is not available.

The following describes the first version of the installation procedure for sites starting from the GKS source code. This should be the case only for those institutes which are the first to order a licence to run the GTS-GRAL software under UNIX on a machine type which is not available at CERN, and for which no other institute has yet installed the software.

For CERN-supported systems other than UNIX, affiliated institutes are able legally to receive only the GTS-GRAL kernel and driver libraries, and the driver source, but NOT the kernel source. This requirement has been relaxed for UNIX in order to support machines not available at CERN, but in this case the institute must sign a source licence with GTS-GRAL, for which there will be no charge. (If compiled libraries are already available, then the distribution is as described in section on Page .)

Once the software has been delivered and compiled, the institute is requested to act as a subsidiary distribution centre to CERN, so that the libraries may be made available to institutes which later request support for the same machine type. However, they should only distribute libraries if authorized to do so. CERN can make available example scripts to be used in order to build a tar distribution file.

The source code is made available in a tree stored in a tar file called unix_src.tar, which can be distributed either on tape or via a network (eg via FTP). Later, there may be a distinction made between the OLD, PROduction, and NEW versions.

The first thing to do is to create a root directory, for example, /user/gts-root, and set this as current. The tar file should then be copied to this root from tape or via a network, and then be unpacked:

mkdir /user/gts-root
(cp-or-ftp-or-mv  unix_src.tar /user/gts-root/unix_src.tar)
cd    /user/gts-root
tar   -xf unix_src.tar .

So far the development has been done at CERN on an Apollo DN3000 under SR 10.2 using SYSTYPE 'sys5.3', and the tar file has been moved to CRAY X/MP and Y/MP machines, SEL Gould, and a DECstation RISC under Ultrix. In all cases both GKS and GKS-3D have been compiled successfully. The drivers tested have been the ones for PostScript, the 2D metafile driver, the Apollo GPR and GSR drivers, and the Tektronix 4107 (on the DECstation).

Any problems and/or modifications made to code or scripts should be carefully commented and sent to GRAPHICS@CERNVM.CERN.CH in order that they may be incorporated in later versions.

Tar file contents.

The root contains the directories bin, dmo, doc, gks, gks3d, and utl, plus the files:

.login

C shell login script

.cshrc

C shell new process script

startgks

Script to define symbolic names (Bourne or C shell)

startgks.apollo

Apollo development version of startgks

startgks.cray

CRAY version of startgks

startgks.ux

Ultrix version of startgks

c_system_rebuild

Re-build GKS, GKS-3D, and driver libraries

c_gkslib_create

Create GKS library

c_gksdriv_create

Create Driver library

c_gkslib3d_create

Create GKS-3D library

compcc

Compile all C routines (*.c) in a directory and insert them into a library. (Uses the symbol '$ccomp')

compf

Compile all Fortran routines (*.f) in a directory and insert them into a library. (Uses the symbol '$fortran')

c_fort

Apollo only; this uses the Aegis Fortran compiler

c_fix_include

Utility to convert format of INCLUDE statement

c_gks_comp_single

Compile routine and replace in a library

c_gkz_compile

Utility to test compile gkz routines only

lkgks2d

Example script to link a GKS application

lkgks3d

Example script to link a GKS-3D application

rencmn

Utility to convert .cmn file names to upper case

reninc

Utility to convert .inc file names to upper case

renfor

Utility to convert .for file names .f file names

renftn

Utility to convert .ftn file names .f file names

help.unix

UNIX help file

help.changes

The list of updates made to date

help.driver

Some notes on how to write a driver

help.errors

List of GKS Error codes

demo

GTS-GRAL demo programs

drivers

driver source

kernel

kernel source with CERN mods

kernel.original

original of routines modified by CERN

fonts

data files for software fonts

libs

(empty) directory for libraries

demo

GTS-GRAL demo programs

kernel

kernel source with CERN mods

kernel.original

original of routines modified by CERN

exe

data files for demos

libs

(empty) directory for libraries

driver.list

file defining which drivers to compile

gkx

gkx utility routines with CERN mods

gkx.original

original of routines modified by CERN

gkz

copy of relevant gkz.xxx directory

gkz.standard

gkz machine-dependent routines with CERN mods

gkz.original

original of routines modified by CERN

gkz.apollo

gkz routines for Apollo

gkz.cray

gkz routines for CRAY

metafile

2D metafile driver for GKS-3D

tek4014

Tektronix 4014 driver

tek4107

Tektronix 4107 driver

vev9c

Versatec driver

xxpscrip

PostScript driver

gks_enum

Include file for GKS enumerated types

gks_gtsdev

Include file for GTS-GRAL workstation type codes

gks_implem.gts

data file used by various GKSPACK routines

gkspack.build

script to unpack gkspack.car

gkspack.car

GKSPACK 'CAR' file

gkspack.f

GKSPACK Fortran source for UNIX systems

gkspack_test.f

Simple GKSPACK test program

grconv

Script used for metafile conversion

gredit.f

Source of editor part of GRVIEW program

grview

Script used for metafile viewing and editing

grview.comp

Script used to build GRVIEW

grview.f

Source of GRVIEW program

Procedure

1. Edit the .login and .cshrc to set the local value for $gkshome, etc. if the C shell is being used, and make sure they are executed. (If using the Bourne or Korn shells, then modify the files as necessary.)
2. Rename the most appropriate file to $gkshome/bin/startgks and edit it to set up local conditions. Then execute it, for example by typing 'source startgks' under the C shell. The points to watch for include:
   • Use of Bourne Shell or C Shell
   • Use of UNIX System V or BSD 4.2,
   • Local home directory definition (if not set in .login file)
   • Local Fortran and C command syntax
   • Local librarian. ie bld not ar, or special ar syntax. Note that if ar must be used under BSD without ranlib, then the use of ranlib must be uncommented in the files c_gkslib_create, c_gksdriv_create, and c_gkslib3d_create.
   • Ensure definitions of gkschXX are correct.
3. If necessary (eg under Ultrix, SEL-Gould, or perhaps other BSD systems) edit the files c_gks*create and c_gks_comp_single in order to remove the comment character in front of the ranlib command.
4. Process all Fortran files to change the format of the INCLUDE statement to whatever works locally. (They are delivered using VMS format.) This may be done with the script $gkstools/c_fix_include after setting the target working directory as current. Modify c_fix_include as necessary.
5. Replace the files in $gkshome/gks/drivers/gkz with the set most appropriate to the local system. It may be necessary to edit all the .c files in order to change the subroutine names to/from upper/lower case with/without a trailing underscore, etc. There exist already directories gkz.cray, gkz.apollo and gkz.standard all under $gkshome/gks/drivers and, as delivered, gkz contains the files from gkz.standard. Make sure that you start with the most appropriate set of gkz files. Copy the tree using (eg) the command:

   $gkstools/c_cpt $gkshome/gks/drivers/gkz.cray $gkshome/gks/drivers/gkz
   

   Note that C routines for different machines have the following characteristics:

   STANDARD

   global symbolic names are lower case with trailing underscore.

   CRAY

   global symbolic names are upper case with no underscore.

   APOLLO

   global symbolic names are lower case with no underscore if Aegis Fortran compiler is used. (This is the CERN recommendation, and is backwards compatible from SR 10 to SR 9.7)

6. Edit the file $gksdrivlist to specify the drivers you wish to include. The file has one line per driver, with the format 'dn name'. The first character is a literal 'd' and is followed by an integer which numbers the lines. The second argument is the name of the sub-directory below $gkshome/gks/drivers containing the driver which is to be added.
7. Edit the routines $gkshome/gks/kernel/gkddlk.f and $gkshome/gks3d/kernel/gkddlk.f (they are not identical) to ensure that the drivers included in $gksdrivlist are known to GKS and GKS-3D.
8. Execute $gkstools/c_system_rebuild (and cross your fingers).
9. Check that the environment variable GKS_FONTS is defined correctly and is available to all users.

Problem areas

There may be problems in the following areas:

1. Although most compilers accept the INCLUDE statement, this is not defined in the Fortran 77 standard, and so its syntax may be vary on different machines.
2. The format of External Global Symbol Names is not defined anywhere to be a standard, even though most UNIX systems use lower case symbol names with a trailing underscore. This is crucial for the linking of routines written in different languages. (GKSGRAL uses the languages Fortran *and* C.)
3. Machine dependencies in some of the gkz routines. GTS-GRAL have tried to keep all system dependencies within these routines. If UNIX were really a standard then there should be nothing to change. Nevertheless, there are variations, (eg gkzof for opening files, etc).
4. Special features of local compilers.
5. Some BSD implementations seem to use ar without ranlib. In this case use of ranlib must be uncommented in the files c_gkslib_create, c_gksdriv_create and c_gkslib3d_create.