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
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
All public include files, such as
pkg_err files, will be found in
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:
Links are then set up to the public include files in
/star/include using the appropriate pkg_dev
script. For example:
SAE_PAR is defined by
For C programs, includes take the normal form:
-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
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
% alink [
-xdbx] file [arguments]
upson SunOS, by supplying dummy source files for required ADAM system routines. It also has the effect of inserting a
-goption into the argument list. For more details, see Appendix B.
.c, the file will be compiled appropriately; if none of the permitted extensions is given,
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
may specify the name with no extension ( or
.o). The object files for any compiled C files
will always be retained.
In most cases it will be:
pkg is the specific software item name e.g.
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
(See Appendix B for more details.)
Interface Files may be compiled by the
compifl program which is available in
Compiled Interface Files (
.ifcs) must be produced on the platform on which they are to be
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.
The top-level routine for Unix A-task monoliths should be of the form:
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:
Separate Interface Files are required for each action run from the shell – a monolithic Interface File is required for monoliths run from ICL.