=============================================================================== *********************************** **** IRAF Version 2.15 Release **** *********************************** ** Mar 2, 2010 - V2.15-ALPHA for PCIX (Source/OSX/Linux, 32 and 64-bit) ** Mar 24, 2010 - Bugfix update of distribution ** May 23, 2010 - Bugfix update of distribution ** Sep 19, 2010 - Bugfix update of distribution ** Nov 21, 2010 - v2.15EXPORT release ** Jan 26, 2011 - v2.15.1 Patch release ** Feb 21, 2011 - v2.15.1a Patch release ================================================================================ This directory and its subdirectories contains the network version of the full IRAF V2.15EXPORT distribution. README This file PORT.GUIDE 64-bit IRAF Software Porting Guide COPYRIGHTS Copyright information for this software bugs.log System buglog (known bugs to date) help.log System helplog (user tips to date) v215revs.txt V2.15 revisions summary, text version sysnotes.v215 V2.15 detailed system revisons notes sysnotes.v2151 V2.15.1 detailed system revisons notes sysnotes.v2151a V2.15.1a detailed system revisons notes v2151-announce.txt V2.15.1 release announcement v2151a-announce.txt V2.15.1a release announcement PCIX PC-IRAF distribution - Linux/OSX 32- and 64-bit SSOL SUN-IRAF distribution - SunOS/Solaris for Sparc CPU PORT Source and binary distributions used for porting to new platforms See below for information on what it is contained (and what isn't), how to upgrade/install this release, who should install it, and what to look for in terms of potential problems. Questions or problem should be directed to the IRAF user-support forums at http://iraf.net. Contents: --------- 1) What is the IRAF V2.15 Release - What it contains, and what is still missing - What has been tested, and what hasn't - Mac OSX Binary Changes - Deprecation of 'redhat' architecture 2) Who Should Install - Distribution file 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 4) Dynamic Loading of External Packages 5) Mixed 64-bit IRAF and 32-bit External Packages 6) Known Problems 7) V2.RELEASE Modification History ================================================================================ ---------------------------------- 1) What is the IRAF V2.15 Release ---------------------------------- IRAF V2.15 is a major release of the IRAF system for all supported platforms. The main feature of this release is support for 64-bit Linux and Mac OSX systems, although there are numerous other enhancements as well. Because changes to the system interfaces were fairly substantial, an extended test release was made available to the community to gather feedback about potential problems in the science code. There were only a few reported problems and we now consider the system to be stable for general release. Note that it is NOT necessary for any external package (or locally developed code) to be fully ported to 64-bits or modified to use the new architecture names for that package to continue to be used under v2.15. IRAF v2.15 is designed to operate with older versions of code even if the base IRAF system is a newer architecture. Users should, however, consult the release notes to decide which, if any, changes may require packages to be modified to operate correctly. What it contains, and What is still missing ------------------------------------------- V2.15 is a cumulative patch of all applications and system interfaces since the last release, as well as a port of IRAF to 64-bit platforms. In short, this release contains o IRAF V2.15 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 and PPC systems Cygwin, FreeBSD and Solaris x86 updates to v2.15 are pending. There are also a number of new features that have changed the system significantly enough to warrant a major release. Specifically, o A port to 64-bit OSX and Linux systems o Simplified external package installation o A single 'linux' architecture for 32-bit Linux systems o Universal (intel and ppc) binaries for OSX 32-bit systems o A simplified IRAF build-from-source procedure o The TABLES.TTOOLS package is now distributed as UTILITIES.NTTOOLS o The libtbtables.a library from TABLES now included in the core release o Compile-time prototype checking of code to reduce errors o A new MEMIO interface to detect pointer over/underflows, provide memory garbage collection, usage reporting, and more o A new SVG graphics device for better web-presentation of plots o Numerous bug fixes and minor enhancements The one major feature missing from the planned V2.15 system with this release is a simplified network install script. While the distribution file is now is now a single download file that includes both source and binaries in a unified directory tree, our plan is to further simplify the process to allow both a system-wide installation as well as a personal installation that does not require root permission to install. The plan is to have a network install script to download and unpack needed files (both the IRAF base system and external packages), this will be released shortly as a separate project. What has been tested, and what hasn't ------------------------------------- The primary work on v2.15 was the port to 64-bit platforms. The approach taken required changes to data structure definitions (see details in the Port Guide) in core system interfaces, a new memory management interface and application-specific changes where external formats are used (e.g. binary file formats requiring 32-bit integers). These changes were tested individually, however it isn't always possible to test every application that uses a particular interface. As a normal part of the port process, the "images" test scripts we maintain were run on each platform. These scripts exercise key image applications and interfaces (e.g. IMCOMBINE or image interpolation) and we're confident the current release has not changed the results. Specifically, o Tests run on v2.15 and v2.14 systems show identical values on 32-bit systems. o Tests run on v2.15 64-bit systems are either the same or within floating-point precision as compared to 32-bit systems. o Comparison of 32-bit and 64-bit results between Linux and Mac OSX systems are within expected floating-point precision differences. o Image (and binary table) data created on 32-bit machines can be read on 64-bit machines, and vice versa. o Spot checking of applications revealed a few problems which have been fixed. What we have NOT been able to test as extensively are the science applications and 3rd-party external packages. We have relied on the user community and the extended test period to reveal problems with these applications. Because of data structure changes and the new memory interface, we expect that long-standing problems in applications will show up as new bugs, i.e. a bug that caused no apparent damage on 32-bit machines will crash as a 64-bit task. Similarly, we hope users will be able to verify that results from 64-bit applications match those from earlier IRAF versions or from equivalent 32-bit tasks. 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. Mac OSX Binary Changes ---------------------- In previous IRAF releases, the Mac architectures were defined as macintel OSX (Intel) binaries (32-bit) macosx OSX (PPC) binaries (32-bit) With this release we were faced with the prospect of a new Mac architecture for 64-bit Intel or some other form of reorganization. Rough statistics indicated that users are spread about evenly between the 32-bit ppc and intel systems and new 64-bit Snow Leopard systems. However, since all new Mac machines will be 64-bit capable and come with OSX 10.6 (or above), we opted to combine the 'macosx' architecture into a single i386/ppc Universal 32-bit binary and use the existing 'macintel' architecture for 64-bit Intel binaries. Therefore the new architecture definitions are: macintel OSX (Intel) binaries (64-bit) macosx OSX (Intel/PPC) Universal binaries (32-bit) This change primarily affects Mac Intel users still running 10.5 (or earlier) or 10.6 users on older hardware not capable of running 64-bit binaries. These users were previously required to use the 'macintel' architecture but will now be required to use 'macosx'. This change is done automatically in the 'cl' login command, but is something to keep in mind for users who explicity set an IRAFARCH environment variable. Users should note that the test for whether IRAF determines the platform to be a 32-bit 'macosx' arch or the 64-bit 'macintel' is the result of the system "uname -m" command (returning 'i386' or 'x86_64' respectively). Hardware capable of running 64-bit binaries might, in fact, be running a 32-bit kernel and thus require the 'macosx' arch. The "IRAFARCH" environment variable can be defined to be 'macintel' to force the architecture to be used, however we assume that the 64-bit kernel is used on systems where 64-bit binaries are desired. It is not easy for IRAF to determine when a system is capable of running the 64-bit binaries and so we rely on users to configure their system for 64-bit as needed. Further info on booting your system to 64-bit mode can be found at http://www.hackaapl.com/forcing-snow-leopard-os-x-to-boot-64-bit-kernel/ and elsewhere via a Google search. Deprecation of 'redhat' architecture ------------------------------------ Another architecture name-change in V2.15 is the introduction of a single 'linux' architecture for all 32-bit Linux distributions. In earlier releases the 'suse' architecture was removed, and likewise the original need for having separate 'redhat', 'suse' and 'linux' binaries (i.e. incompatabilities in the GCC interface) has been redundant for quite a while. Maintaining these separate Linux versions is no longer required. Note that external packages using the older redhat/linux binary naming convention may continue to be used without change. Even though the v2.15 core system architecture is now 'linux' for all 32-bit systems, the search path for task binaries was modified to look to older architecture names so that legacy code may continue to be used. ---------------------- 2) Who Should Install ---------------------- IRAF v2.15 is REQUIRED for all users of 64-bit platforms, it is RECOMMENDED as the release for all other 32-bit systems. Distribution Files and Patch Releases ------------------------------------- The main IRAF distribution files are build for the latest release of the system (at this writing, v2.15.1a) meaning that new users will always be instaling the latest release. Patch files are built as an increment to the previous release, meaning that e.g. the 'patch1' release file applies the v2.15.1 patch to the original IRAF v2.15 release. As an exception, the 'patch1' file in this case applies the v2.15.1a patch to the base IRAF v2.15 release due to the short interval between releases and the desire to avoid requiring future users to install multiple patch files for a minor change. Patch files include source code changes as well as needed binaries for the patch. Because the v2.15.1 patch included changes to core system libraries that affect all tasks the patch file is unusually large. We expect that in future patches only a small number of binaries will need to be included. ------------------------------- 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/unix/hlib/install script to install the system - 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 - I am installing multiple IRAF versions: 1) Create a new 'iraf' root directory and unpack the distribution file for the host platform 2) Define $iraf in your environment to be the full path to the IRAF system you wish to be the system-wide default. If this is the existing iraf installation you can skip this step, to make the v215 the default you'll redefine $iraf and run the install script 3) 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 distro 3) Define $iraf, $IRAFARCH in your environment and source the $iraf/unix/hlib/irafuser.csh script. Note a C-shell is required for this step 4) Run the $iraf/unix/hlib/install script to install the system 5) Configure the directory tree for the proper architecture and compile, e.g. on a 64-bit linux system: % cd /iraf/iraf % setenv iraf /iraf/iraf/ <-- trailing '/' required % setenv IRAFARCH linux64 <-- set system architecture % source $iraf/unix/hlib/irafuser.csh % make linux64 <-- reset system % make sysgen <-- compile from source In future versions this process will be made more robust and automatic, the above steps should compile the complete system. - I want to install IRAF to support multiple platforms: 1) Create an 'iraf' directory (preferrably /iraf/iraf) and unpack the distribution file for your primary platform there. 2) For each additional plaform you want, either unpack the distro file for that platform in the same directory (this is redundant to install sources but will overlay the additional binaries easily), or get the appropriate IB and NB distribution files and unpack each file manually in the iraf$bin. and iraf$noao/bin. directory. Note there are combined Linux (iraf-linux.tar.gz) and OSX (iraf-osx.tar.gz) distribution files as well as a single distribution that includes all supported binaries (iraf-all.tar.gz) 3) Define $iraf in your environment (with a trailing '/') 4) Run the $iraf/unix/hlib/install script to install the system 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. ---------------------------------------- 4) Dynamic Loading of External Packages ---------------------------------------- Dynamic package loading is a new feature 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.15 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 INSTALLATION! 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.15 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 support. 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 rsponsibility of the distribution maintainers (by default this is NOAO). Please contact us if you wish to have your package added to the system. Repositories ------------ 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 in most cases. 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.15 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.15. 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 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: -.tar.gz 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.15 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 andmacosx architectures. In some cases, external packages can/will not be ported to 64-bit systems or otherwise updated with a new release, v2.15 is designed to allow these older packages automatically to continue to be used whenever possible. ------------------ 6) Known Problems ------------------ During development several problems were identified that were tabled for a later fix since they aren't expected to impact many users initially. These include: o A transient IMCOMBINE crash: possible memory error that seems to happen when imcombine is used for a lengthy period during scripts. o The XREGISTER task on 64-bit linux has a transient crash. o "Fast" I/O mode is imio is temporarily disabled due to an undiagnosed problem that affects image file size. o Cross-compilation of 32-bit linux from 64-bit system produces binaries that segfault (compat lib issues?) ------------------------------------- 7) V2.15RELEASE Modification History ------------------------------------- Nov 22, 2010 Initial IRAF v2.15 release Jan 26, 2011 IRAF v2.15.1 Patch release Feb 21, 2011 IRAF v2.15.1a Patch release