iraf.net

Hello - I have downloaded and attempted to install the 64-bit version 2.16.1 version on my iMac. Although the installer appears to run fine, when I try to run "cl" or "iraf", I get the following error:

$ cl
Segmentation fault: 11

and nothing happens. I installed the following binaries:
iraf.macx.x86_64.tar.gz

My machine parameters are:
$ uname -a
Darwin hcastronomy-12.local 11.4.2 Darwin Kernel Version 11.4.2: Thu Aug 23 16:25:48 PDT 2012; rootnu-1699.32.7~1/RELEASE_X86_64 x86_64

Mac OS X Lion 10.7.5 (11G63)

Any help would be excellent! Thanks!

- Jonathan

To follow up on this, I also get the following errors when I try to run "make latest" and "make check_update":





Note the double forward slash in the F77 and F2C variables.

The segfault is happening because of an incompatibility between the new binaries and pre-10.8 versions of OSX. A set of 64-bit 'macintel' binaries built on a 10.6 machine is available from

ftp://iraf.noao.edu/pub/fitz/iraf.macx.x86_64-10.6-tar.gz

Simply download these in binary mode and unpack in your /Users/jhargis/iraf directory with the command

% tar zxf /path/iraf.macx.x86_64-10.6-tar.gz

This will replace the binaries you currently have for the core system, NOAO and VO packages and should get things working again.

For external packages you may need to relink the package after installing it if you see the same segfault error, most of the packages should work fine but post back if you have problems.

Hi - Thanks so much for the new binaries. I installed these and IRAF will now load. However, I am having problems displaying images using mscdisplay. I did rebuild the mscdb, mscred, stsdas, tables, fitsutils packages after reinstalling IRAF.

When loading an MEF fits file using mscdisplay, the image does not load in ds9 (either version 7.1 or 7.2). No error message is given initially, but when I logout I get the error:



The "display" routine appears to work fine and will display both normal FITS images and particular extensions of the MEF fits files. I have tried this with both MOSAIC fits files and new DECam fits files. The DECam images do give the warning:



The errors/warnings occur regardless of whether I "set use_new_imt = no". This seems to make no difference. Could this be an issue with xgterm or ximtool not being the proper build for my OS? Can you provide a link to xgterm/ximtool for Lion?

When you rebuilt the package binaries, did you first do an e.g.

% mkpkg -p mscred macintel

to reset the architecture? If not, the new binaries may have ended up in the mscred$bin.generic directory and so you are still using the original binaries, however if you get a parameter prompt and don't see a segfault then they may be working anyway. If the binaries are indeed in bin.generic you can simply move them to the bin.macintel directory or else delete them and reset the arch before compiling again. Note however that some of STSDAS (and parts of TABLES, I think) can't be compiled due to sources removed before distribution.

DS9 7.2 should not be used since it is known to be broken regarding reading cursor positions from IRAF, but I believe 7.1 worked. Otherwise, do you get any sort of error message (e.g. 'cannot open device') from the display or does it appear to work but no image appears? Since DISPLAY appears to work I think the connection is fine and the problem may be with the data itself, e.g. is there actually an extension having the EXTNAME="tile13" keyword? Do other tasks like MSCSTAT work on these files?

Lastly, if xgterm and ximtool start then there is no need for a different binary.

Hi - Thanks for the response. The binaries were in the /extern/mscred/bin.macintel directory. However, I had not issued the mkpkg command. However, issuing that command gives a series of error messages. Just to clarify, here is what I did in the extern/ directory:

1) "make init" to start fresh
2) ./configure
3) "mkpkg -p mscred macintel", which gives the errors:



4) Since the files didn't obviously exist, I issued the command "make mscred" which appeared to install properly.

5) Tried "mkpkg -p mscred macintel" but it gave the same errors.

The mscredlib directory does not exist. At what step is this supposed to be created?

Thanks,
Jonathan

Hi - Just to follow-up on the MSCDISPLAY issue, I do not believe this is a problem with the data. I have tried loading raw MOSAIC data but it will not display (with no error message). Also, MSCSTAT will not run on these images either and gives no error message.

Thanks,
Jonathan

The "mscredlib" should actually read "mscred/lib", i.e. the expansion of the path mscred$lib is missing the trailing '/'. You can workaround this by setting the 'mscred' environment variable explicitly before compiling:

% setenv mscred /Users/jhargis/iraf/extern/mscred/ # remember trailing '/'
% mkpkg -p mscred macintel
% mkpkg -p mscred

The initial "make mscred" to install the package should define this but I'll double check that the trailing '/' is included.

If this successfully produces a new binary in the right place and you still have problems, please upload a sample image to the anonymous ftp at ftp://iraf.noao.edu/pub.

Regardless of the display issues, if you do an MSCSTAT of the image and then do a 'flpr', do you see the same 'abnormal termination' message?

Hi - I have added the environment variable, but the mkpkg routine will still not run. I no longer get the error message for the incorrect path, but something still cannot find the mkpkg routine. Here is the full output of exactly what I am doing:

The "make mscred" command is issued from the iraf$extern directory.

The "mkpkg -p mscred macintel" command is issued from the MSCRED package directory, i.e. iraf$extern/mscred. I think you simply need to 'cd' into the package dir before giving the command.

Hi - Ok, thanks for clarifying. This appeared to work. For the STSDAS and TABLES packages, however, it does not appear that all the binaries/libraries were built (if I compare the bin.macintel/ results to the bin.macos/ results). How do I build and install the STSDAS and TABLES packages?

The best you can do is "make stsdas" (TABLES will be installed automatically) to install the distributed version of the packages from STScI. Due to licensing issues some of the source is now removed from the package before distribution so building completely from source is no longer allowed. That said, a large number of binaries not affected by the removals will still build. Additionally, it may be that you can still relink the binaries using the libraries distributed with the package, although I haven't tried.

I believe STSDAS/TABLES are still built against an older v2.14 system (and are 32-bit anyway) so this may all be moot, I wouldn't worry about relinking/building these unless/until you have an actual problem. At that point, you might also want to mail help@stsci.edu

Hi - Ok, sounds good. Thanks for your invaluable help in getting this up-and-running!

- Jonathan