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.
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:
Links are then set up to the public include files in /star/include using the appropriate pkg_dev
script. For example:
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:
(-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 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.
.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.
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.)
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.
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.