### 6 Compiling and Linking

6.4 Monoliths

Originally ADAM programs were always written in Fortran, the top-level module being written as a subroutine with a single INTEGER argument, the ADAM status. The link scripts now also accept C functions. If the top-level function is a C function, it must have a single argument of type int *. If it is not written as a Fortran-callable routine, the source file must be presented to the link script.

Note that the complete set of C interfaces for the Starlink libraries is not yet available so it may not be possible to write your program entirely in C without the aid of something like the CNF package (see SUN/209).

To compile and link ADAM programs, it is necessary to add /star/bin to your PATH environment variable. This is done if you have ‘sourced’ /star/etc/login to set up for Starlink software generally.

#### 6.1 Include Files

All public include files, such as pkg_par and pkg_err files, will be found in /star/include.

The filenames of the Fortran include files are in lower case but they should be specified in the program in the standard Starlink way. That is, for example:

INCLUDE ’SAE_PAR’
INCLUDE ’PAR_ERR’

Links are then set up to the public include files in /star/include using the appropriate pkg_dev script. For example:

% par_dev

creates links PAR_PAR and PAR_ERR to /star/include/par_par and /star/include/par_err respectively. (SAE_PAR is defined by star_dev.)

For C programs, includes take the normal form:

#include "par_err.h"

(-I/star/include is included in the link scripts).

Two shell scripts are provided to link ADAM programs. alink is used to link A-tasks and A-task monoliths, and ilink to link I-tasks. The executable images produced may be run either from a suitable user-interface such as ICL, or directly from the shell.

The following description uses alink in examples; ilink is used in the same way.

To link an ADAM program, ensure that /star/bin is added to your environment variable PATH, then type:

% alink [-xdbx] file [arguments]

Where:

-xdbx
optional (but must be the first argument if used), overcomes some problems with debugging ADAM tasks, notably with xdbx and ups on SunOS, by supplying dummy source files for required ADAM system routines. It also has the effect of inserting a -g option into the argument list. For more details, see Appendix B.
prog_module
specifies a file containing the task’s main subroutine. The filename should be of the form path/name.f, path/name.c, path/name.o or path/name. The path/ component is optional but name must be the name of the program’s main subroutine and will be the name of the executable file produced in the current working directory. If the file extension is .f or .c, the file will be compiled appropriately; if none of the permitted extensions is given, .o is appended.

Note that after a .f file has been compiled, on some platforms the .o file will be retained in the current working directory so that subsequent alinks with an unchanged .f file may specify the name with no extension ( or .o). The object files for any compiled C files will always be retained.

arguments
optional, is any additional arguments (library specifications, compiler options etc.) legal for the Fortran compiler, or any C files to be compiled separately and linked in. The list of Starlink libraries automatically included in the link is given in Appendix C; the method of including other Starlink libraries in ADAM programs will be specified in the relevant Starlink User Note.

In most cases it will be:

% alinkprog_module ‘pkg_link_adam‘

where pkg is the specific software item name e.g. ndf.

Appendix B gives details of the command used within alink/ilink to compile and/or link the tasks. This may assist users who wish to alter the standard behaviour.

By default, programs are statically linked with the Starlink libraries. On platforms where shared libraries are installed, programs may be linked with them by setting the environment variable ALINK_FLAGS1 appropriately. On currently supported systems it should be set to -L/star/share. (See Appendix B for more details.)

#### 6.3 Interface Files

Interface Files may be compiled by the compifl program which is available in /star/bin. Compiled Interface Files (.ifcs) must be produced on the platform on which they are to be used.

Generally, the only things which will need changing when porting Interface Files between operating systems are file and device names. Case is significant on Unix and obviously the format of filenames is different from VMS, for example.

#### 6.4 Monoliths

The top-level routine for Unix A-task monoliths should be of the form:

SUBROUTINE TEST( STATUS )
INCLUDE ’SAE_PAR’
INCLUDE ’PAR_PAR’

INTEGER STATUS

CHARACTER*(PAR__SZNAM) NAME

IF (STATUS.NE.SAI__OK) RETURN

*       Get the action name
CALL TASK_GET_NAME( NAME, STATUS )

*       Call the appropriate action routine
IF (NAME.EQ.’TEST1’) THEN
CALL TEST1(STATUS)
ELSE IF (NAME.EQ.’TEST2’) THEN
CALL TEST2(STATUS)
ELSE IF (NAME.EQ.’TEST3’) THEN
CALL TEST3(STATUS)
END IF
END

To run such a monolith from a Unix shell, link the required action name to the monolith, then execute the linkname (possibly via an alias). For example:

% ln -s \$KAPPA_DIR/kappa add