The initial release of IRAF V2.14 is now available from links in the Downloads area and on the IRAF archive at iraf.noao.edu. The release is for PC-IRAF systems only (Linux, Mac OSX (Intel or PPC) and Cygwin). Additional binaries and platforms will be added in subsequent releases. For the impatient, the README file is attached in the body of the story.

Update (2/19/08) Solaris x86 binaries have been added to the distribution.

Critical Update (1/14/08) A crticial bug has been discovered in an IMIO interface routine that affects ALL tasks linked against V2.14. This bug causes bogus pixel values to be returned leading to corrupted images and/or unexplained system crashes. All users are strongly encouraged to re-install the IB and NB binary distributions with patched versions from the download area ASAP. Reinstalling the source distribution is NOT required (but does include the IMEDIT change mentioned below). We apologize for the oversight, please post problems or questions as they arise, see the README file addendum for details.

Errata: (12/18/07)The IMEDIT task has new parameters that are missing from the v2.14 distribution file. See this thread for details.


		     README FOR PC-IRAF VERSION 2.14
		       Updated  December 1, 2007
		    Current Patch Level V2.14-EXPORT


##############################################################################

1-Dec-2007	    *** Initial V2.14 EXPORT Release ***
		    (Linux, MacOSX (Intel/PPC), and Cygwin)


IRAF V2.14 is a major-version release of the system and requires a FULL
INSTALLATION of the package, even if you have an existing V2.13 system.
The Installation Guide (pciraf.ps.Z) contains a detailed description of
the installation process for both first-time installations and updates
to existing systems.  Installation will require downloading the AS, IB,
and NB distribution files from this directory.  The AS distribution is
common to all PC-IRAF platforms and is required for any installation.
There are separate sets of binaries (the IB and NB distributions) for
each PC-IRAF platform and only those binaries required for a particular
platform will need to be downloaded.

PC-IRAF V2.14 supports the following platforms:


  System			  Distribution    Additional Systems
  ------			  ------------    ------------------
  MacOSX 10.4 and higher	  MACX	    	  (Intel or PPC arch)
  Linux RedHat 9	    	  RHUX	    	  Fedora, Enterprise, CentOS
  Debian 3.1 (Sarge) and higher   LNUX	    	  Other Debian-based systems
					              and all other linux
  Cygwin 		    	  CYGW	    	  Windows XP only


  ** NOTE:  The SUSE architecture has been dropped as of this release,
	    however support for SuSE systems is available in the LNUX
	    architecture.  Future releases may seek to merge RHUX and
	    LNUX into a single Linux platform release to minimize the
	    number of required distributions.


All versions are supported with a single IRAF distribution, although you
need to install separate binaries for for each platform.

The IRAF distribution does not itself include graphics and image display
tools; these are distributed separately.  XGterm is required for any IRAF
task which does vector graphics or which has a GUI.  Any of the XImtool,
DS9 or SAOimage image display servers may be used for image interaction.
See ftp://iraf.noao.edu/iraf/x11iraf/ for the latest X11IRAF tools
(XGterm/XImtool) and SAO for information about DS9.

See also the post-distribution notes at the end of this file.  These are
continually updated after the release as any problems are encountered.

##############################################################################


Contents
--------

    1. Introduction
	1.1 The Purpose of this Release
	1.2 The PC-IRAF V2.14 Distribution
	1.3 Who Should Upgrade?
	1.4 IRAF User Support

    2. Highlights of this Release

    3. Installing PC-IRAF
	3.1 MacOSX Technical Notes
	    3.1.1 Optimization Changes For MAC OS X
	    3.1.2 Leopard (OSX 10.5) Support
	    3.1.3 The Mac OS X 'iraf' user account
	3.2 Things to Watch Out For
	    3.2.1 External Package Support
	    3.2.2 Special Note to Linux Kernel 2.6 Users
	    3.2.3 Special Note to Linux IMFORT Users
	    3.2.4 Special Note to Developers Using Cygwin

    4. X11/GUI Support
	4.1 The GUIAPPS External Package
	4.2 24-bit XImtool Support (Coming Soon!)

    5. Notes Added Since the Initial Release


-----------------------------------------------------------------------------
1. INTRODUCTION
-----------------------------------------------------------------------------

1.1 THE PURPOSE OF THIS RELEASE
-------------------------------

As of September 2007, NOAO has resumed development of IRAF on a limited
scale, although primary responsibility for user support remains at the
community IRAF.NET web site.  IRAF V2.14 is a formalized version of the
IRAF.NET V2.13 releases previously made available by iraf.net.

The major version number increaase is meant to disambiguate NOAO
releases from earlier versions and to provide a clean code base for
future development.  Unlike earlier 'major' IRAF releases that contained
substantial new functionality, this release may seem a bit lacking.
Support for Intel-based Mac and Cygwin platforms is the key highlight
as well as many unseen but required maintenance/viability changes.
A number of new tasks and features have been added, either inherited
from the V2.13 releases or done as part of external package development.
See Section 2 for details about changes in this release.



1.2 THE PC-IRAF V2.14 DISTRIBUTION
----------------------------------

PC-IRAF V2.14 is a port of IRAF to PC platforms running any of a number
of Linux distributions, Mac OSX (Intel and PPC) and Cygwin (Windows XP).
Beginning with IRAF V2.11, a single version of PC-IRAF installed on a
central server can simultaneously support IRAF sessions running on any
combination of PC systems or servers.


    README	    This file

    as.pcix.gen.gz  All-Sources (main IRAF distribution)	(21 Mb)

    ib.cygw.x86.gz  Core system binaries for Cygwin  		(12 Mb)
    ib.lnux.x86.gz  Core system binaries for Linux (generic)  	(12 Mb)
    ib.macx.ppc.gz  Core system binaries for MacOSX (PPC)	(20 Mb)
    ib.macx.x86.gz  Core system binaries for MacOSX (Intel)	(16 Mb)
    ib.rhux.x86.gz  Core system binaries for RedHat Linux  	(12 Mb)

    nb.cygw.x86.gz  NOAO package binaries for Cygwin  		(14 Mb)
    nb.lnux.x86.gz  NOAO package binaries for Linux (generic)  	(14 Mb)
    nb.macx.ppc.gz  NOAO package binaries for MacOSX (PPC)	(24 Mb)
    nb.macx.x86.gz  NOAO package binaries for MacOSX (Intel)	(20 Mb)
    nb.rhux.x86.gz  NOAO package binaries for RedHat Linux  	(14 Mb)

    pciraf.ps.gz    PC-IRAF Installation Guide (compressed)
    pciraf.ms.gz    PC-IRAF Installation Guide (troff source)
    unixsmg.ps.gz   IRAF Site Manager's Guide (compressed)
    unixsmg.ms.gz   IRAF Site Manager's Guide (troff source)


Each of the AS, IB, and NB distribution files is available as a single file
for more convenient downloading over high-bandwidth Internet connections.
The Installation Guide provides detailed instructions on how to use these
files to install IRAF.  A complete installation requires that the user
obtain the AS source distribution (in this case the 'as.pcix.gen.gz' file)
and at least one set of IB and NB binary distribution (e.g. 'ib.rhux.x86.gz'
and 'nb.rhux.x86.gz' for a RedHat Linux system, or 'ib.macx.ppc.gz' and
'nb.macx.ppc.gz' for a MacOSX PPC system).



1.3 WHO SHOULD UPGRADE?
-----------------------

IRAF V2.14 is a major-version IRAF release for all supported IRAF platforms.
Support for older versions of IRAF is limited so sites running earlier
versions of IRAF should update to the new version of IRAF.

There may be incompatibilities between V2.14 and earlier versions of IRAF,
so updating in the middle of an analysis program might not be advisable.
In general, reducing data using different versions of IRAF will work in most
cases, but there can be complications due to parameter or algorithm changes.
Users are advised to review the system revisions notes for changes that
may affect them.

Large installations may want to keep and older version of IRAF around to
give users time to complete their programs before switching to the new
version of IRAF (e.g. here at NOAO, the "cl" command runs V2.14, and an
"irafo" command will bring up the older V2.12.2b release).  An 'iraf'
command can be created by copying the hlin$cl.csh script and defining
a value for $iraf that points to the old version at the top of the file.
Note that only one version if the system can be "installed" at any one time
for compilation, i.e. links such as for 'xc' and 'mkpkg', users will need to
override this in their environment if they wish to compile against an older
version of IRAF.  Questions about this may be posted to https://iraf.net



1.3 IRAF USER SUPPORT
---------------------

Although NOAO has resumed limited development of IRAF, it has not resumed
the general email-based user support system.  New external packages such
as NVO and NEWFIRM being developed as part of other initiatives will be
released with information pointer users to project-specific help available
for those packages.  This project-based help will be supported by NOAO
for some period of time during development and initial deployment, but
does not include core IRAF support at this time.

The community-based site, https://iraf.net,  will remain primarily
responsible for IRAF and most external package support.  IRAF developers
will continue to participate in the IRAF.NET forums even for those projects
not being supported by NOAO, and for question posted about projects that
might have other support within NOAO.

We are counting on input from the community to guide further development
of all projects and feedback at IRAF.NET will be used to determine future
work undertaken at NOAO.  We thank you in advance for your input.




-----------------------------------------------------------------------------
2. HIGHLIGHTS OF THIS RELEASE
-----------------------------------------------------------------------------

The primary changes to IRAF V2.14 were done to support the new Mac Intel
and Cygwin platforms, as well as fix long-standing issues with the viability
of the system on recent Linux and Mac OS X systems.  However, a number of
key features and tasks will be new to users.

The following list is a partial summary of changes in this release:

    o Mac (Intel) Now a Supported Platform

    o Cygwin (for Windows XP) Now a Supported Platform

    o SUSE dropped as system architecture

    o ECL Now Default Interpreter
	Starting with this release, the 'cl' command to start IRAF will
	invoke the ECL interpreter as the default.  Users can still access
	the old CL by starting with the command "% cl -o"

    o FITS Now Default Image File Format
	Starting with this release, FITS will be the default image format
	for all output images.  Use of OIF (i.e. the ".imh" format) is
	still available by changing the 'imtype' variable setting.

    o ZPN Projection now supported by all tasks using the MWCS interface 
	The ZPN projection driver from the Cambridge Astronomical Survey
	Unit was installed in the MWCS interface.  ZPN is a zenithal/azimuthal
	polynomial projection.

    o RV.FXCOR now fits Gaussian peaks using double precision.  Additionally
	the HJD output is printed to 5 decimals precision.

    o Access to 2MASS and USNO-B1 catalogs from the ASTCAT package


    o Display overlay colors may be set with expressions
	- The masks specified by the 'bpmask' or 'overlay' parameters may now
	  be set using image data or colors represented by expressions.  See
	  the 'Overlay Colors' section of the DISPLAY help page for details.

	- Transparent masks (using the name 'transparent' or a mapped color
	  less than zero) are now permitted.

    o IMEDIT has the following changes:
        1.  A new option to do vector constant replacement was added.  This
	    is particularly useful for editing bad pixel masks.
        2.  New options '=', '' to replace all pixels with values
            ==, = to the value at the cursor with the constant value
            was added.  This is useful for editing object masks.
        3.  The '?' help page is now set by an environment variable rather 
	    than hardcoded to a file in lib$src.  The environment variable
	    is imedit_help and is set in tv.cl to point to the file in the
            source directory.


    o New Tasks In the System:

         images.tv:
            BPMEDIT - Examine and edit bad pixel masks associated with images

         images.imcoords:
             MKCWCS - Make or update a simple celestial wcs
            MKCWWCS - Make or update a simple celestial/wavelength 3D wcs

         lists:
           RAVERAGE - Compute running average, standard deviation and envelope

         noao.nproto:
             SKYSEP - Compute are separation between two RA/Dec values
           SKYGROUP - Group a list containing RA/Dec into spatial sublists

    o New Parameters

         images.imutil:
	    HSELECT - Added a 'missing' parameter to be used when keywords
	  	      isn't in header.


    o New Environment Variables

	- Two new environment variables are available for use in IRAF
	  networking:

              KS_RETRY, if defined, is the number of retry attempts using 
		the default rsh (or KSRSH) protocol.  The task will sleep 
		for 1 second between attempts and then loop back to try 
		again to make the connection. This is meant to avoid potential 
        	clashes between multiple machines connecting simultaneously 
		as with the pipeline.

	      KS_NO_RETRY which when defined instructs the task *not* to 
		attempt a retry using the fallback rexec protocol.  This test
		is made after the KS_RETRY checks to allow for various 
        	combinations of settings to allow the code to skip retries
		entirely (i.e. define only KS_NO_RETRY), retry using the 
		default protocol but not with rexec (i.e. define KS_RETRY 
		as some value and set KS_NO_RETRY), or retry only with rexec
		(i.e. old behavior, don't define anything).

    o Increased Buffer Sizes
	- Various environment buffers were increased to allow for longer
	  settings of $PATH or other strings that would occassionally
	  overflow.
	- SZ_IMNAME was increased from 79 to 128 characters.
	- SZ_ERRMSG in system error strings increased from 80 chars to
	  SZ_LINE (1023) to allow inclusion of full paths in error messages.
	- The FFT procedures in the VOPS interface now permit vectors of
	  2^31 points (up from 2^15)

    o New Developer Libraries.  
	Several new libraries are available for SPP developers:

      	   - Installed the 'mef' library from the FITSUTIL package for doing
    	     general MEF manipulation.  This will remove the dependency on 
	     FITSUTIL from several external packages.

	   - Installed the 'dbc' routines from the FITSUTIL package.  This 
	     is an extension to the imgead header database routines that 
	     allow for a comment field to be created/manipulated in the 
	     header.

	   - xtools$xtargs.x is a simple interface to parse an argument 
	     string consisting of a list of whitespace separated keyw=value
	     pairs.


-----------------------------------------------------------------------------
3. INSTALLING PC-IRAF
-----------------------------------------------------------------------------

The procedure for installing PC-IRAF is unchanged from earlier versions
of PC-IRAF.  Refer to the PC-IRAF Installation Guide (pciraf.ps.Z) for
detailed installation instructions.  A full installation, as for any
major release, will be required.

The installation guide contains the full installation instructions (see also
the notes below) but one thing is worth emphasizing here: the installation
will be simplified if you set up the iraf directories as follows:


    /iraf				root of iraf related files
    /iraf/iraf			root iraf directory (AS dist)
    /iraf/irafbin			iraf bin dirs go here
    /iraf/irafbin/bin.redhat	RedHat binaries for core system
    /iraf/irafbin/noao.bin.redhat	RedHat binaries for noao packages
    /iraf/irafbin/bin.linux	Linux binaries for core system
    /iraf/irafbin/noao.bin.linux	Linux binaries for noao packages
		:				:
    /iraf/extern			external packages (tables etc.)


Here "" is the path where all this is located, e.g., "/u3/iraf"
on the IRAF development system here at NOAO.  The path can be anything,
although it is best to keep it short.  You might want to also set up a
symbolic link "/iraf" pointing to the "/iraf" directory.  This allows
all iraf files to be referred to relative to /iraf, regardless of where
the files actually are located, and agrees with the default configuration
used in the distribution files.  Having such a link when IRAF is served
from a central NFS system also allows all clients in the network to use
a common "/iraf/iraf" root directory regardless of the NFS mount points.
Graphically such a tree would look something like (for a RedHat-only system)


                            /iraf
                            /  
                   (AS) /iraf /irafbin
                                /   
                    (IB) bin.redhat  noao.bin.redhat (NB)


The graph indicates where each of the three distribution sets should
be unpacked.  The "iraf root directory" in this case is /iraf/iraf, this
is the value you enter to the install script.  See the installation guide
for details, specifically the Appendices which give a complete examples.

The V2.14 PC-IRAF release supports several architectures;


    System		        Distribution       	Architecture
    ------		        ------------       	------------
    MacOSX 10.4 and up     	MACX			macosx (PPC)
    MacOSX 10.4 and up     	MACX			macintel (Intel)
    RedHat Linux 9 and up      	RHUX			redhat
    RedHat Fedora/Enterprise    RHUX			redhat
    CentOS			RHUX			redhat
    Cygwin			CYGW			cygwin
    Debian 3.1 and up 	        LNUX			linux
    All Other Linux  	        LNUX			linux

    * Additional platform supprt will be added in future releases.


A separate set of CORE and NOAO binaries is provided for each architecture.
The all-sources (AS) distribution supports both architectures.  The binaries
which are correct for your system are identified by the "Distribution"
type, however when creating the IRAF tree for unpacking the system you
should create directories according to the "Architecture" name or they
will not be recognized.  Note that systems such as RHUX for RedHat Linux
are appropriate for Fedora Linux systems as well, almost all other linux
distributions not handled by specially built IRAF binaries should probably
use the LNUX system.


3.1 MACOSX TECHINICAL NOTES
---------------------------

3.1.1 OPTIMIZATION CHANGES FOR MAC OS X
---------------------------------------

At some point in the OS X 10.4 upgrade cycle, the original changes made in
the V2.13 release to the floating-point exception handling (which used to
work) were being silently disabled.  This was traced to a GCC compiler
optimizer bug of some kind, meaning that IRAF code compiled with ANY
level of optization would fail to trap any divide-by-zero, overflow,
etc exceptions in the system.  After a lengthy and detailed search,
the exact file triggering this error has not been located.

As a result, the initial V2.14 release for Mac OSX systems (Intel and PPC)
were compiled WITHOUT OPTIMIZATION.  Benchmarks indicate this penalizes
the performance of code by only about 6% in overall usage, less depending
on the specific task.

It was felt that the ability to properly trap errors and produce correct
results was more important than saving typically a second or two during
normal processing.  The default compiler flags for this platform have been
set so that outside developers or users compiling locally will likewise
produce the correct error-trapping code.


An example program one can use to see whether FPE handling is working
properly would be something like:

	task fpe = t_fpe

	procedure t_fpe()
	real    x, y, z
	begin
	    call eprintf ("Begin FPE Test ...n")
	    x = 1.0
	    y = 0.0
	    z = x / y
	    call eprintf ("End FPE Test ...n")
	end

This can be compiled as

	% xc fpe.x			# no optimization (default)
	% xc -/O3 fpe.x			# compiled w/ optimization

Note however that the second example will execute to completion rather
than stop with the expected "floating point divide by zero" message.
The value of the 'z' variable is undefined, and the task may appear
"hang" in some instances.  Users are STRONGLY DISCOURAGED from changing
the optimization level on their own until this problem is better understood.


3.1.2 LEOPARD (OSX 10.5) SUPPORT
---------------------------------------

The V2.14 release was delayed slightly so that it could be tested against
the new release of OS X 10.5 (Leopard) recently made available.  We are
happy to report that pre-built binaries as well as local compilation both
appear to work WITHOUT PROBLEM on Leopard.

Users should note however that, binaries compiled under 10.5 will not run
under earlier releases.  Therefore, IRAF and external package binaries
being made available were compiled on the latest OS X 10.4.11 release.


3.1.3 THE MAC OS X 'IRAF' USER ACCOUNT
--------------------------------------

Under MacOSX it turns out to be difficult to change the iraf account login
directory once it is created.  The system wants to keep the login directory
in /Users/iraf where IRAF wants it to be iraf$local (this can be fixed
as root using nidump/niload, but it is not easy and could be dangerous).
For the time being we are recommending that users simply create the iraf
account but leave it to the install script to handle setting up links
as needed so the proper environ- ment is maintained as on other systems.
See the PC-IRAF Installation Guide for more information on how this part
of the installation differs from other platforms.



3.2.1 EXTERNAL PACKAGE SUPPORT
------------------------------

Since Macintel and Cygwin are new ports, many older external packages
may not yet support, or have been tested with, these platforms.  In most
cases however, all that will be required to use such a package with IRAF
is to modify the root mkpkg file to add an entry for the "macintel" and/or
"cygwin" architecture, then build the package.

Prebuilt binaries for some of the most popular external packages are already
available and will be maintained on https://iraf.net.  Users should post
question about support for particular packages to the forums at IRAF.NET,
Known roblems and workarounds for packages will be posted there as well.

For the impatient, the mkpkg at the root of each external package will
usually require a branch to set the architecture prior to compilation.
The statements to be added (at the end of the file) will typically look
something like:

    cygwin:                                # install Cygwin binaries
            $ifnfile (bin.cygwin)
                !mkdir bin.cygwin
            $endif
            $verbose off
            $set DIRS = "lib src"
            !$(hlib)/mkfloat.csh cygwin -d $(DIRS)
            ;
    macintel:                              # install MacOSX Intel binaries
            $ifnfile (bin.macintel)
                !mkdir bin.macintel
            $endif
            $verbose off
            $set DIRS = "lib src"
            !$(hlib)/mkfloat.csh macintel -d $(DIRS)
            ;

Existing entries for the package should be used as a guide; in particular
the directories listed in the "$set DIRS = ...." line must be consistent
for the package to be modified correctly.  With this change most external
packages can be built as they would on any other platform.  Packages for
which NOAO is responsible are available on iraf.noao.edu in the directory
ftp://iraf.noao.edu/iraf/extern.  Software from other sources may require
you to make this change yourself prior to building the package.



3.2 THINGS TO WATCH OUT FOR
---------------------------

Please see the release notes for information on what has changed in V2.14,
and things to watch out for.

As with any major release, we STRONGLY recommend that each user reinitialize
their 'uparm' directory to pick up the numerous task and package parameter
changes in this release.  IRAF V2.14 does not require this if you are
upgrading from V2.13, but it is still strongly recommended. The uparm
directory may be reinitialized by issuing a new MKIRAF command prior to
logging into the system.



3.2.2 SPECIAL NOTE TO LINUX KERNEL 2.6 USERS
--------------------------------------------

Recent Linux systems based on the 2.4 and 2.6 kernels demonstrate a
potential problem with the interaction between the MEMIO interface and
user resource settings.  Specifically, pointers allocated in the normal
course of a task may occassionally be at an address outside the user's
per-process stack space, resulting in a "memory has been corrupted" or
"segmentation violation" error.  The workaround is to remove the stacksize
limit in the user's shell with a command such as


        limit stacksize unlimited               # for tcsh users
        ulimit -s unlimited                     # for bash users

      
As a preventive measure against this problem, the CL startup script was
modified to implement this change and so most users who only use IRAF from
the CL will not need to take any special action.  This remains an issue
for IMFORT tasks however, and users may need to use one of the above 
commands to get the tasks to run correctly.


3.2.3 SPECIAL NOTE TO LINUX IMFORT USERS
----------------------------------------

In addition to the stack size problems above, platform support is further
complicated by changes to glibc and the 'ld' loader on some newer linux
distributions, which resulted either in unresolved symbols or a segfault
from the loader itself.  Users would see various combinations of those
problems depending on the distribution being used.

To fix the unresolved symbol problem the compatability library 'libcompat.a'
(found in the iraf$unix/bin.) was updated to include the missing
symbols from older glibc versions and the XC compiler modified to use
this library on more platforms.  The loader segfault is caused by the
definition of the "Mem common" symbol "mem_" at address zero in the one
and only assembler routine in IRAF (all iraf pointers are relative to
this address).  To fix this problem it was necessary to define the symbol
on the GCC command-line instead, again by modifying the XC compiler to
do this automatically.

These changes will be transparent to people compiling external packages,
SPP sources using the XC compiler directly, or IMFORT programs using the
FC command under the CL and only affect Linux platforms.  However, users
who build their IMFORT programs by calling the Fortran/C compiler directly
with absolute paths to the needed IRAF libraries, say from a Makefile,
will need to adjust their link line to include the compatability library
and the extra linker argument.

        To summarize, an imfort program built with F77/G77, and *not* the
iraf XC/FC compilers, must now be linked as something like


  g77 myprog.f 
      -L/iraf/iraf/bin.                  that do use
such macros.  Compilation of these files will fail (typicall with a "define
too long" error) under Cygwin without some sort of corrective action.
The  file is the only file in the core system that could be
problematic, however similar structures may be present in external packages.

The first thing to check is whether the  or similar include file
is actually needed by the code.  If not, the simplest solution is to
remove the include dependency and compilation should proceed normally.
If however, the include file IS required, then the file can be compiled
using the package "special files" list.

All packages should contain a 'mkpkg.inc' file that can be used to include
platform-specific definitions.  This will typically appear as a block of
code something like:

	$ifeq (MACH, linux, redhat, macosx, macintel) then
	    $include "hlib$mkpkg.sf.MACX"
	$else $ifeq (MACH, linux, redhat, linuxppc) then
	    $include "hlib$mkpkg.sf.LNUX"
	$else $ifeq (MACH, cygwin) then
	    $include "hlib$mkpkg.sf.CYGW"
	$end

In this case the 'hlib$mkpkg.sf.CYGW' file is read for 'cygwin'
architectures.  This is the special-files list and may contain something
like

	# These routines use local include files with multi-line macros
	$set    XARCH   = '& "$xc -c -A &"'
	$special "mypkg$pkg/":
	        foo.x       $(XARCH)
        ;

Here, the file 'foo.x' in the mypkg$pkg directory will be compiled using
the flags specially defined in the XARCH setting.  Specifically, the use
of the '-A' flag will compile the code to use a modified version of 
that defines the multi-line macro in  on a single line.

Summary:

    - If your code uses , use the special-files list to compile it 
	using the modified version as described above.

    - If your code defines it's own multi-line macro, you can modify the 
	macro to be defined on a single line to avoid this error.


Contact IRAF.NET if you have questions or run into problems.  For users,
installing pre-built binaries is the best solution.  Developers may wish
to modify their code to workaround this issue until it is resolved in
the system.



-----------------------------------------------------------------------------
4. X11/GUI SUPPORT
-----------------------------------------------------------------------------

IRAF V2.14 includes full support for the X11IRAF utilities - these include
'xgterm' for xterm-compatible terminal emulation and graphics, and 'ximtool'
for image display under X.  The X11IRAF package is not included in IRAF;
you need to get it and install it separately, as you would any other
X software.  X11IRAF is available in /iraf/x11iraf on the main IRAF
network server (iraf.noao.edu) or from https://iraf.net.

This software is continually under development and new versions appear
on a timetable independent of that for the main IRAF distribution.

Other IRAF-compatible GUIs can also be used with IRAF, e.g. DS9 or SAOimage.
Users should check the appropriate web sites at SAO for the latest releases
and new about these applications.



4.1 THE GUIAPPS EXTERNAL PACKAGE
--------------------------------

Some time ago we started a project to develop prototype IRAF applications
with integral GUIs (graphical user interfaces).  These applications have
since served their purpose in prototyping new technology for science GUIs
and component-based applications in IRAF.  The GUI applications are much
more than just technology prototypes however: these are very useful science
applications with many new features, with a nice graphical user interface
to boot. With the release of IRAF V2.11.3 and X11IRAF V1.2 several years
ago, it became possible to wrap up work on the GUI prototypes and get
them out for people to use.

The prototype GUI applications are contained in the package GUIAPPS
available from the /iraf/extern directory of the IRAF archive, and contain
the following tasks:

              demo - GUI Demo Task
               spt - SPECTOOL Package
             xhelp - GUI Help Browser Task
               xrv - GUI Version of the RV Package
           xapphot - GUI Aperture Photometry Package

Note that starting with V2.12, the XHELP task is included as part of the
core system as a special device type (e.g. "help implot dev=gui" will
run HELP as a GUI task).  The GUI tasks require that the user be running
an XGterm graphics window (from X11IRAF) in order to display the GUI:
Xterm users WILL NOT be able to use the GUIs presently.

To install the package users should download the 'guiapps.tar.gz' file from
the IRAF archive directory and uncompress/untar it in the local external
package directory (typically /iraf/extern).  Detailed installation inst-
ructions are 'guiapps.readme' file  in the same directory.

More information of the GUIAPPS package is available from the project
page at http://iraf.noao.edu/iraf/web/projects/guiapps/.

	
4.2 24-bit XImtool Support (Coming Soon!)
-----------------------------------------

As of this writing, support for XImtool running under "24-bit" TrueColor
displays is in progress.  Releases and further details will be forthcoming
on the iraf.net and iraf.noao.edu web sites.




-----------------------------------------------------------------------------
5. NOTES ADDED SINCE THE LAST RELEASE.
-----------------------------------------------------------------------------
Jan 14, 2008

        A critical bug was found in an IMIO interface routine that would
    cause zero or non-sensical value to be returned for the last two pixels
    of a 1-D image section.  Since such sections could be generated by any
    task using e.g. imgs2s() to loop over rows, the bug affects ALL tasks.
    In some cases the bad pixels would cause black stripes to appear in a
    processed image (e.g. from XREGISTER), in other cases it could lead to
    a segfault or FPE crash.
        The bug was fixed and a new set of binaries generated for all
    platforms with advice that all users update ASAP.

Jan 14, 2008
        Since a new binary is required anyway, an additional fix to the 
    timezone computation for Mac systems was also released.  On these systems
    the GMT offset includes the DST and so an extra hour was erroneously
    being added to the local time.

Comments (0)