Welcome to iraf.net Saturday, January 20 2018 @ 10:52 PM GMT

IRAF v2.16.1 Patch Now Available

  • Tuesday, October 22 2013 @ 02:40 AM GMT
  • Contributed by:
  • Views: 6,888

An IRAF v2.16.1 Patch release is now available from the IRAF anonymous ftp archive at

This patch is a minor update of the IRAF v2.16 release for all 32- and 64-bit Linux and Mac OSX systems. Thsi release fixes a number of known bugs in the system but primarily features a greatly simplified installation procedure for users without root access on the machine. Major features of this release include:

     Non-root Install default      Global login
     C-shell not required          32-bit OSX changes
     Automatic update checking     X11IRAF tools included

Numerous other bug fixes, feature updates and enhancements are included as well. Details of this patch and upgrade instructions may be found in the release announcement below. Users running the original IRAF v2.16 release can update using the commands:

    % cd $iraf ; make latest

Update 10/30/13: 1) External packages have all been relinked against v2.16.1 (except the 32-bit only STSDAS/TABLES) and can be updated with a "make latest" command from the $iraf directory. PPC binaries are coming. 2) more bugs than I would like in the new install scripts have been fixed, existing installations can likewise update to get the updates. 3) No problems seen with new OSX Mavericks update in this version (however you must update XCode and reinstall XQuartz).

                 **** IRAF Version 2.16.1 Release ****

**  Release history
**   3/22/12   Initial IRAF v2.16 Release
**  10/17/13   Intitial Release: V2.16.1 for PCIX (Src/OSX/Linux, 32 and 64-bit)



   1)  What is the IRAF V2.16.1 Patch Release
   2)  Who Should Install
         -  Distribution files and patch releases
   3)  How to Install This Release
         -  I am installing for the First Time
         -  I am replacing an existing IRAF installation
         -  I am installing multiple IRAF versions
         -  I want to build the IRAF system from source
         -  I want to install IRAF to support multiple platforms
     3.1) Upgrading External Packages
     3.2) Mixed 64-bit IRAF and 32-bit External Packages
     3.3) System Requirements and Dependencies
   4)  Dynamic Loading of External Packages
   5)  Mixed 64-bit IRAF and 32-bit External Packages
   6)  Known Problems
   7)  V2.16 Release Modification History


1)  What is the IRAF V2.16.1 Patch Release

    IRAF V2.16.1 is a patch release of the IRAF v2.16 system for all
supported Linux and OSX platforms.  This is primarily a bug-fix release,
however there are several significant updates related to the installation
procedures included as part of this release.

    This release is a cumulative patch of all applications and system
interfaces since the initial v2.16 release.

In summary, this release contains

    o	IRAF V2.16.1 updates for the following architectures:

	    linux	All 32-bit linux systems
	    linux64	All 64-bit linux systems
	    macintel	64-bit Mac OSX (10.6, Intel only) systems
	    macosx	32-bit Mac OSX (10.4+) Intel systems (default)
	    macosx	32-bit Mac OSX (10.4+) PPC systems (optional)

	Cygwin, FreeBSD and Solaris x86 updates to v2.16 are possible
	given sufficient user interest, however we do not plan to port to
	these systems unless there is a compelling demand from the

    o	32-bit OSX binary changes

	    Beginning with this release, the 32-bit OSX 'macosx' architecture
	will no longer be a Universal i386/ppc binary.  Instead, due to the
	limited demand for PPC systems (and waning support from Apple) we've
	decided to separate these binaries into individual distributions for
	each platform.

    o	Non-root installation option

	    Beginning with this release, root user permissions are no longer
	*required* for a working IRAF system; by default, the iraf$install
	script will do a "personal installation" of all files to the dir-
	ectory $HOME/.iraf and modify the user's login/shell-setup files to
	define a working runtime and build environment.  The process of
	downloading, unpacking and installing IRAF can all be done from a
	normal user account, and the installed system will supercede any
	existing IRAF version on the machine.
	    In summary, a full installation can be accomplished by:

		1) Download the distribution file
		2) Create an iraf directory and unpack the system
		3) Go to that directory
		4) Run the install script as "./install"

	In most cases you can simply accept the prompt defaults, however you
	should review the values before accepting.

	    The install script can optionally also be run with a "--system"
	flag (as 'root' or with 'sudo') to do an installation to system
	directories as before.   This form of installation is required if you
	plan to use IRAF networking on the machine.  It can also be run in
	this mode *in addition* to a personal install if you plan to use the
	global login mechanism (see below).

	***  Important notes:

	    1) 	The default personal install will modify the following files
		in your $HOME directory (if they exist):

			.login	   .cshrc
			.bashrc    .profile	.bash_profile

		A backup of these files will be created with a ".bak"
		extension, and this file will be modified only once.

	    2)  Spaces in path names (e.g. "/Users/Jane Smith/") are NOT
		supported at this time.  If your $HOME directory contains
		a space, a system install is recommended.

    o	Global login.cl/uparm

	    With a personal installation, the $HOME/.iraf directory will
	contain not only a bin directory of IRAF commands and runtime files
	(e.g. the "iraf.h" link), but the install script will also create a
	default login.cl file and uparm directory.  The CL has been
	modified such that if there is no login.cl file in the current
	directory, these global login files will be used, i.e. it is now
	possible to login to IRAF from *any* directory on the machine
	without an error.  Users can likewise choose to create the
	$HOME/.iraf/loginuser.cl file to be used for global definitions.

	    This global login method can be overridden by local files when
	needed.  If you run MKIRAF in a given directory, then starting IRAF
	in that directory will use the local login.cl/uparm files.
	Similarly, a loginuser.cl file in the current directory will
	override a loginuser.cl in the $HOME/.iraf directory.  Lastly, it
	is possible to create a 'uparm' directory that will be used to
	store the parameters when logging in from that directory.  The
	flexibility of these methods means that users can exclusively use
	the global login, always use directory-specific login files, or
	some combination.

    o	New task to check for system updates

	    A new CHKUPDATE task hase been added to the SYSTEM package and
	is called automatically in the login.cl file.  The purpose of the task
	is to check the NOAO distribution servers for an available IRAF update.
	This task will check only every  days, where  is set by the 
	'interval' parameter to the task.  You can set the 'interval' param-
	eter to -1 to disable the checks entirely (or comment out the task
	from the login.cl file), to zero to check with each login, or to
	some positive number which will be the number of days before checking
	again for an update.
	    If the specified interval has passed a message will be printed 
	on the login banner indicating whether the installed system is
	current or if an update is available.

    o	C-shell no longer required

	    In IRAF v2.16.1 we have re-written all of the shell scripts used
	in the runtime system to use the Bourne shell instead of the C-shell
	from previous releases.  These older scripts are still available and
	can be installed for use by running the install script as

		% ./install --csh

	On newer Linux and OSX systems where Bash shell is the default for
	user accounts, the private installation will modify the Bash shell
	setup files to define a proper IRAF environment.  If an account is
	configured to use the C-shell the appropriate setup files for that
	shell will also be modified.  

	    C-shell scripts are still used in a few places in the third-party
	iraf$vendor code however these are only needed when building completely
	from source.  These scripts will be replaced in a future update.

    o	X11IRAF binaries distributed with IRAF

	    Since XGterm/XImtool have long been needed for a working IRAF
	system anyway, we've decided to now include these binaries with the
	core distribution.  The install script will create the appropriate
	links to these files and once installed, both commands will be

    o  	Update SLALIB version to GPL licensed version

     	   Replaced the SLALIB with the GPL'd version from Starlink per a 
	request by Pat Wallace.  This updates the library to v2.5-2 and 
	includes updates to the leap-second table to 2012.  The IRAF 
	copyright was not edited into the files, instead each file contains
	the GPL copyright (full text of which is in SLA_CONDITIONS.

    o	32-bit OSX Platform Support

	The v2.16 release featured Universal (i.e. Intel and PPC) binaries
	for the 'macosx' architecture.  Since the initial release however
	it has become clear that PPC support is needed by only a handful
	of users and the burden of providing a Universal OSX binary is 
	not worth the cost of supporting such a release.  As a result, 
	we've changed the definition of the 'macosx' architecture to refer
	only to the 32-bit Intel systems with the v2.16.1 release.  Support
	for PPC systems will still be provided

    o	Updated compiler support

	Mkpkg files and compiler flags set in the XC compiler have been
	modified to support recent GCC 4.4 compilers without error.
	Additionally, the HSI code has been modified to compile cleanly
	(i.e. no warning produced when compiling with '-Wall').

    o   Increased number of allowed background jobs

	The max number of background jobs allowed by the CL has been
	increased from 4 to 32.

    o  	Updated versions of TOPCAT and ALADIN.

    o  	Numerous bug fixes and minor enhancements

    When reporting a bug or problem,  please be sure to indicate the
platform used and supply whatever information (parameters or data) is
necessary to reproduce the problem.  If you are reporting a problem with a
Virtual Observatory data service, please also indicate which service and
what task was used to access it.

2)  Who Should Install

    IRAF v2.16.1 is RECOMMENDED FOR ALL USERS.  Although the VO features are
optional, v2.16.1 contains a number of important bug fixes (especially for
those on 64-bit platforms).

Distribution Files and Patch Releases

    The main IRAF distribution files are build for the latest release of
the system (at this writing, v2.16) meaning that new users will always be
instaling the most current release.  Patch files will be built as a
cumulative patch to the initial release, meaning that e.g. the 'patch1'
release file applies the v2.16.1 patch to the original IRAF v2.16 release.
Patch files include source code changes as well as needed binaries for the

    Because bugs in or changes to the new core system capabilities will
require a complete set of binaries, installation of patches has now been
automated using a mechanism similar to what's done for external packages.
At this writing, there are no patches available, however the installation
of future patches will be a matter of simply:

	% cd $iraf		# go to the iraf root dir
	% make latest		# download and install latest patch

Additional targets in the toplevel Makefile include:

     make latest                Update entire system (core + extpkgs)
     make latest_src            Update only source code
     make latest_core           Update only the core iraf system

     make check_latest          Check is system is latest released version

3)  How to Install This Release

    To install this release, you should download the binary distribution
file appropriate for your machine (either linux or osx) and then identify
yourself as one of the following users and follow the steps described:

    - I am installing for the First Time:

	1)  Create an 'iraf' directory (preferrably /iraf/iraf) and unpack
	    the distribution file for your platform there.
	2)  Define $iraf in your environment (with a trailing '/')
	3)  Run the $iraf/install script to install the system for personal
	    use (or with root permission and the '--system' flag for a
	    system installation).

    - I am replacing an existing IRAF installation:

	1)  Save any local configuration file (graphcap, extern.pkg, etc)
	    of the existing IRAF installation to a separate directory
	2)  Delete the existing IRAF tree
	3)  Unpack the distribution in the existing iraf root directory
	4)  Replace/merge local configuration files
	5)  Optionally run the $iraf/install script to install the system
	    so that a global login may be used.

    - I am installing multiple IRAF versions:

	1)  Create a new 'iraf' root directory and unpack the distribution 
	    file for the host platform
	2a) If you wish to use the new IRAF v2.16.1 version as the default,
	    execute the iraf$install script to create a personal login.

	2b) If you want to select which system to use, set $iraf and $IRAFARCH
	    in your environment as appropriate for the desired version before
	    running the 'cl' command or compiling software.

    - I want to build the IRAF system from source:

	1)  Download the iraf-src.tar.gz (or as.pcix.gen.gz) source-only 
	    distribution file
	2)  Create a new iraf root directory and unpack the distribution
	3)  Execute the iraf$install script to create needed links.
	4)  Configure the directory tree for the proper architecture and
	    compile, e.g. on a 64-bit linux system:

		% make linux64			<-- reset system arch
		% make sysgen			<-- compile from source

    - I want to install IRAF to support multiple platforms:

	1)  The 'iraf-all', 'iraf-linux', and 'iraf-macosx' distributions
	    represent various combinations of platforms one might typically
	    use.  These should be installed per the instructions above.  
	2)  To develop or recompile the system, switch between systems
	    by reconfiguring the architecture, e.g.

		% make linux64		# set linux64 arch
		% make update		# compile recent changes
		% make linux		# set linux arch
		% make update		# compile recent changes

    We recommend if possible that a dedicated machine be used for testing
to avoid possible confusion with a multi-version system.  Note that while
environment variables can typically be used to control which version of
IRAF is started, these same environment variables when defined in startup
files such as .login or .cshrc can cause confusion when building software.

3.1) Upgrading External Packages

    External packages available under v2.16 will continue to be available
using the same installation procedures.  New binaries for these packages
are required so that the new core capabilities will be available to external
tasks as well.

    However, only those packages that were previously updated to support
v2.15 can be linked against the v2.16 libraries.  This means that packages
such as STSDAS/TABLES and other third-party packages that remain 32-bit
only are unchanged.  These packages can continue to be installed using
the external package 'make' mechanism, but will not have VO capabilities.

3.2) Mixed 64-bit IRAF and 32-bit External Packages

    On 64-bit systems it is possible to still use 32-bit external package
binaries (e.g. for packages that haven't been updated yet), however care
must be taken to match the architecture names.

    For example, on Linux systems the arch name is 'linux64' and this
will be used to find binaries in external packages as well.  For packages
such as STSDAS where no 'bin.linux64' binaries are available, you can
simply use the 32-bit binaries by making a 'bin.linux64' symlink that
points to the 'bin.linux' directory.

3.3) System Requirements and Dependencies

    Support for VO data queries is provided by the VOClient interface which
relies on a background Java process to execute the queries and web-service
calls.  Although this process is started transparently by the applications
which need it, Java 1.5 or greater must be available on the machine.

    Additionally, the distributed ECL and VOCL binaries are built
dynamically and assume the CURSES libraries are installed.  This library is
available by default on OSX systems but is often an optional installation
for many Linux distributions.  Details about exactly which package
file is required depend on the distribution being used, however it is
typically named NCURSES (or perhaps TERMCAP on some older distributions).
Statically-linked binaries for ECL and VOCL can be provided upon request.

4)  Dynamic Loading of External Packages

    Dynamic package loading is a feature introduced in v2.15 that allows for
package directories created in the iraf$extern directory to be automatically
defined when the CL is started.  The means that external package installation
no longer *requires* that the hlib$extern.pkg file be edited to define the
package, although that remains an option for packages which somehow cannot
conform to this new scheme.

Getting Started

    The IRAF v2.16 system is shipped with no defined external packages,
instead we assume packages will be installed using this new feature.  To
begin, simply execute the 'configure' script in this directory to create
the files needed.  For example,

	% ./configure

This will create a local 'manifest' file of packages available form
the IRAF reposistory and iraf.noao.edu and skeleton directories of
available packages will be created automatically along with a Makefile
used to do the actual installation.  THIS STEP IS REQUIRED BEFORE PACKAGE

    To get a listing of packages that can be installed, or to check
which installed packages might need to be updated or are newly available,
use the command:

	% make check

Each listed package may then be installed using a simple 'make' command.
For packages not on the list, a manual install is still required.

    The external package tree may be initialize to the distribution state
using the command:

	% make init

Updates to the distribution mechanism itself is done using the command:

	% make self_update

This last command is used to update the system to new features or bug fixes
that might be available as the mechanism evolves.

Installing and Updating Packages

    External packages may now be installed with a command such as:
	% make ctio mscred stsdas

Note that dependency packages for each requested package will automatically
be added to the installation so you do not need to necessarily list every
package (e.g. you'll get FITSUTIL automatically by installing MSCRED).  The
next time you login to the CL the requested package will be defined.

    To update packages to the latest version, use the command

	% make update

The information about available packages will be updated, then a comparison
of the timestamps of your installed packages with those on the repository
will be made.  If newer package versions are available they will be updated
(along with their depencies) automatically.

    If a binary repository distribution of a package is not available
at the moment, a 'source only' distribution will be installed and you will
not a "[SOURCE ONLY]' status from the make command.  The user is then
responsible for compiling th epackages locally even though the package will
still be defined for use (but unusable).  Our goal is to provide a binary
distribution for all available packages we can reasonably support.

How it Works

    This scheme relies on IRAF v2.16 changes to the CL login process to
scan this directory for packages, as well as a server-side respository of
distribution files suited for this method (see below).  The 'configure'
script customizes the package information for your platform and creates a
'Makefile' based on that information.  Subsequent commands update these
files, however we don't yet provide an automated system for multi-platform

    The bulk of the work is done using utility scripts found in the
iraf$util directory and called from the Makefile.  The management of the
repository files is the responsibility of the distribution maintainers (by
default, this is NOAO).  Please contact us if you wish to have your package
added to the system.


    The default package repository is defined in the $iraf/util/pkgrepo
script and may be changed to point to a local respository (e.g. a mirror
site).  It may also be changed by pointing the 'IRAF_REPO' environment
variable to a new URI source, e.g.

	setenv IRAF_REPO  "ftp://localhost/myrepository"

Of course, a network connection is assumed to exist.  Local repositories
may be preferred for faster local access via mirrors, please contact us for
information on creating one.

Server-Side Repository Description

[The following comes from the README file on the repository]

	This is the IRAF v2.16 distribution repository directory.  Files
    here are bundled so as to allow them to operate with the dynamic
    package mechanism or IRAF install procedurs for v2.16. Aside from
    the repository files themselves, this directory contains

	README		  This file 
	REPO.DESC	  A description of each package 
	MK		  Utility script to update repo checksum/manifest

	CHECKSUM	  Checksums files on repo tarballs created by MK
	REPO.MANIFEST	  Manifest file

    The MK script is used to generate the CHECKSUMS file and REPO.MANIFEST
    file automatically, it should be run whenever a package is installed
    or updated.  The REPO.DESC file is a handcrafted description of the
    available package, this is important to describing the dependencies
    of each package.  The MK script is also capable of determining
    which of the available packages may be used on which platform.
    For example, a "redhat" package will suffice for both a linux64
    and linux IRAF system if there is no specific version available.
    The manifest file created will then list the redhat version as the
    file to be installed for the linux/linux64 platforms.

	If a binary distribution for a particular package is not provided,
    the MK script will default to use the source distribution tarball
    (if available).  On the receiving end the user will then have the
    option of compiling the package locally.  The reserved <arch> name
    "universal" is used for script-only packages, or distributions
    containing binaries for all supported platforms.

	When packages are installed in the IRAF dynamic package tree,
    both the REPO.MANIFEST and REPO.DESC files are downloaded.	Scripts
    use these files to build up package lists that are available for a
    particular platform, as well as which packages are required to be
    installed to support the requested package. We assume the REPO.DESC
    file lists full dependencies, e.g. if A requires B, and B requires
    C the the dependency list for A is both B and C.

    The convention for file names is as follows:


    where  is the package name and  is the iraf architecture.

	For external packages, tarfiles are build at the toplevel, i.e.
    when unpacked, a subdirectory of the package is created in th current
    directory.	For IRAF distributions we violate this rule and assume
    the tarball is built from the $iraf root directory.

    When installing a new package, the REPO.DESC file should be edited
    and the MK script should be run.

    When installing an update to an existing repo package, or a new
    architecture version of a package, the MK script should be re-run.

5) Mixed 64-bit IRAF and 32-bit External Packages

    V2.16 is very forgiving in the way that is allows multiple architectures
to be used.  For example, where the core system might be 'linux64', external
packages containing only the 'linux' or older 'redhat' bin directories will
be used automatically when a native binary cannot be found.  The same is true
for mixing the 'macintel' and 'macosx' architectures.

    In some cases, external packages can/will not be ported to 64-bit
systems or otherwise updated with a new release, v2.16 is designed to allow
these older packages automatically to continue to be used whenever possible
based on the last available release.  In many cases this means a package
can be relinked against the latest IRAF version, but only in 32-bit mode.

6)  Known Problems

    There are no known problems with the initial release of v2.16.

7)  V2.16 Release Modification History

Mar 22, 2012	Initial IRAF v2.16 Release
Oct 21, 2013    IRAF v2.16.1 Patch Release

IRAF v2.16.1 Patch Now Available | 5 comments | Create New Account

The following comments are owned by whomever posted them. This site is not responsible for what they say.

  • IRAF v2.16.1 Patch Now Available
  • Authored by: olebole on Friday, May 16 2014 @ 03:35 PM GMT

I'm not sure what the automated tasks would do even if they found a new version

What they usually do is downloading the new version and informing the owner that there is a new version to look at. This is quite helpful if one has to manage 20+ packages.

  • IRAF v2.16.1 Patch Now Available
  • Authored by: olebole on Monday, May 12 2014 @ 04:43 PM GMT
There are some automated compilations, f.e. for Mageia Linux.

The problem is now, if someone wants to recompile and gets the iraf-src tarfile, the automated recompilation would fail since the content is unexpectedly different.

As a Debian developer: even if I don't have a Debian release yet (which would have the same problem), I regularly check the sources of all the packages I maintain to see if there are updates. For IRAF it constantly reported me "2.16 is the latest version", and so I didn't realize for half a year that there is something new.

I would prefer to have one directory (file) per version, even for dot versions. If there is a link from the latest version to a "current" directory, then sites could link to that.

Best regards

  • IRAF v2.16.1 Patch Now Available
  • Authored by: fitz on Monday, May 12 2014 @ 04:29 PM GMT
We're planning to move to new hardware for the main iraf machine sometime soon and can perhaps do this when the FTP archive is reorganized. Since we don't provide package bundles for these systems in the distribution directory I'm not sure what the automated tasks would do even if they found a new version, my main concern is in not creating orphan hyperlinks on web pages, forums, README, etc.
  • IRAF v2.16.1 Patch Now Available
  • Authored by: olebole on Monday, May 12 2014 @ 12:54 PM GMT
Would you consider renaming the directory so that it actually matches the version (2.16.1 instead of 2.16)?
It is quite hard for programs that automatically search for updates to find out whether there is a new version available.

These automatic searches for new versions exist on the major Linux distributions, Debian, Fedora, Gentoo.
  • IRAF v2.16.1 Patch Now Available
  • Authored by: robsteele49 on Thursday, April 20 2017 @ 08:20 PM GMT
Using the instructions provided I was not able to compile for linux64 the V 2.16.1 version of IRAF. Has anyone had any success with this. I am doing this effort and recording my successes and failures at: https://github.com/steelewool/iraf

--- Rob Steele (Robert.D.Steele@jpl.nasa.gov)

Privacy Policy
Terms of Use

User Functions