iraf.net

Hello,I've successfully installed IRAF 2.15 on my Mac running 10.6 (Snow Leopard). The installation mostly went well except that I had to create two symbolic links:/iraf/iraf/bin.macosx -> bin.macintelI ran mkiraf from my home dir and created a login.cl file. When I run cl, I get the following error:ERROR: No /iraf/iraf//bin.ipad/ecl.e binary found.It looks like something is confused about the system on which I am running IRAF (I am not using an iPad). Does anyone have any ideas on how to fix this?Thank you.
Jean Chiar

What distribution file did you download? You shouldn't need to create any link and the Mac files both appear to have bin directories.

I downloaded the Mac OSX 64-bit file (iraf.macx.x86_64.gz).Perhaps I made an error in setting up the directory structure?

Assuming you created a /iraf/iraf directory, all you should need to do is then unpacke the iraf.macx.x86_64.gz file in that directory. There should then be a bin.macintel directory with binaries (same for the noao package).You shouldn't need to create bin.macosx unless for some reason your environment has the architecture confused (e.g. is there a $arch or $IRAFARCH variable defined?). What was the original error that led you to think you needed to create the symlinks in the first place?

I had the same issue. For some reason, the install command identifies my architecture as "macosx" rather than "macintel" for reasons unknown, even though I have a 64-bit machine running Snow Leopard. I just hard-coded the install file to look for the "macintel" directory instead.

The architecture is identified with the command[code:1:1f0636cb8d]/usr/bin/uname -m[/code:1:1f0636cb8d]which should return 'x86_64' on a 64-bit system. Does it?Note that on older Intel systems that can only run 32-bit the proper architecture name is now 'macosx', and the above uname command would say simply 'x86'. There is also now a combo-binary distribution link available that will serve either 32/64 bit systems.

When I run the commamd /usr/bin/uname -m it returns i386. I have a newer Mac with an Intel core i7 which I thought was 64 bit.

I understand the confusion now: There is a complicated history of which machines can/do run 64-bit OSX that basically breaks down to 1) machines which have hardware incapable of running 6-bit OSX (e.g. original Core Duo), 2) machines which *can* run 64-bit OSX (e.g. the later Core 2 Duo), and 3) those machines configured to run the 64-bit OSX by default. I believe it is still the case that 10.6 will run the 32-bit kernel by default, and on machines such as in (2) have the ability to run 64-bit binaries. However, without probing the hardware to see whether a machine is 64-bit enabled, I assume that if you are wanting to use 64-bit then you've setup your system to boot the 64-bit kernel (and hence get the uname 'x86_64').Even if your machine is 64-bit enabled, you'll need to set it up so 64-bit is the default for IRAF to think the architecture is 'macintel' and not 'macosx'. You can do this by manually holding the '6' and '4' keys when booting, or else see e.g.http://www.overclock.net/mac/564147-how-enable-64-bit-default-os.htmlfor a further explanation of the issue and how to make 64-bit the default kernel for your machine (if the machine is capable). This raises a valid point that I should be more clear about this in the release notes, and I'll add that change.

I think it's even more complicated. uname seems to be tied to the version you originally installed on the machine; not the one that's currently running (http://discussions.info.apple.com/message.jspa?messageID=12664329).For example, I have a 64-bit compatible Intel mac, running 10.6.5 with Activity Monitor showing all sorts of running 64-bit tasks, yet "uname -m" reports my CPU architector as "i386" (not "x86_64") and the OS version as 10.5.0.In short, uname on the Mac cannot be trusted.-JS

Right, but as near as I've been able to tell (not having a warehouse of all possible Apple hardware and OS versions), the 'uname -m' should return 'x86_64' when the 64-bit kernel is running (and 'i386' otherwise, there was an earlier problem in a script incorrectly checking the wrong value). Another way to check is[code:1:6f359ced7d]/usr/bin/system_profiler | grep 64-bit[/code:1:6f359ced7d]Which should say 'Yes' when running the 64-bit kernel. I believe I remember there being a vintage of MacBook systems that were 64-bit capable, however Apple had somehow blocked use of the kernel extensions so it never did run in 64-bit mode natively.In any case, you can define a $IRAFARCH environment variable to force iraf to use the 'macintel' architecture and override the 'uname' checks. If this fails for some reason, please post details.

[quote:a5b0873149]n any case, you can define a $IRAFARCH environment variable to force iraf to use the 'macintel' architecture and override the 'uname' checks. If this fails for some reason, please post details.[/quote:a5b0873149]The immediate problem I'm having is that some things are calling "irafarch.csh -actual", which forces the code to ignore $IRAFARCH. Even the installation script itself is creating links to bin.macosx even though I explicitly told it (using the -m flag) that I'm on a macintel architecture [i:a5b0873149]and[/i:a5b0873149] the bin.macosx directory doesn't exists in $iraf. For example,
[quote:a5b0873149]
% ls -l /usr/local/bin/mkpkg
lrwxr-xr-x 1 root wheel 42 Nov 29 13:10 /usr/local/bin/mkpkg@ -> /Users/jstott/IRAF/unix/bin.macosx/mkpkg.e
[/quote:a5b0873149]mkpkg is another one that insists on over-riding $IRAFARCH, which is causing the Makefile in "extern" to report almost everything as "SOURCE ONLY", but I guess I can fall back on building the packages by hand like I always did in 2.14.-JS

I can confirm that setting up my iMac with Snow Leopard to boot into the 64-bit kernel (not the default for any Mac except the Mac Pro and servers) will then yield "x86_64" with the uname command, and IRAF will install without errors. Here's some further info. on how to switch to the 64-bit kernel:http://support.apple.com/kb/HT3773I find only a couple of (non-duplicated) kernel extensions that run only in 32-bit kernels (see "About this Mac" menu, then "More info", then "Software", then "Extensions"), so this should in principle be a safe switch ... but we'll see.

[quote:f2f16db219]
The immediate problem I'm having is that some things are calling "irafarch.csh -actual", which forces the code to ignore $IRAFARCH.
[/quote:f2f16db219]I decided specifically to put off multi-architecture support in the external package scripts to simplify things, however they are clearly needed now. The ability to add packages based on the value of IRAFARCH should now be working if you first do a[code:1:f2f16db219]% cd $iraf/extern ; make self_update[/code:1:f2f16db219]Thereafter you should be able to e.g.[code:1:f2f16db219]% setenv IRAFARCH macosx ; make ctio fitsutil
% setenv IRAFARCH linux64 ; make ctio fitsutil
....and so on[/code:1:f2f16db219]to install different architecture binaries. It is a little inefficient in that the sources are re-retrieved in each architecture bundle, but appears to be working as intended.
[quote:f2f16db219]Even the installation script itself is creating links to bin.macosx even though I explicitly told it (using the -m flag) that I'm on a macintel architecture and the bin.macosx directory doesn't exists in $iraf. [/quote:f2f16db219]This is a minor bug in the install script you can either fix by editing hlib$install so that where it processes the '-m' flag the code reads:[code:1:f2f16db219] case -m: # set machine type
if ("$2" != "") then
shift
else
ERRMSG "missing argument to '-m <mach>' switch"
exit 1
endif
set mach = "$1"
set hmach = "$1" # <------- ADD THIS LINE !!
breaksw
[/code:1:f2f16db219]or you can get a new version from ftp://iraf.noao.edu/iraf/v215/support/install

Hello Mike,I went down this road somewhat as well. My Macbook Pro 10.5.8 with Core Duo 2 gave 'i386' from 'uname -m'. But looking up on-line, the Core Duo 2 were supposed to be 64 bit. So I changed the install script to make it macintel.It installed ok, but then when I tried to run it I gotdyld: unknown required load command 0x80000022 looking this up on google it seemed like some library issue which was beyond me. But somehow in the confusion I ended up on http://www.macupdate.com/app/mac/32252/32--or-64-bit-kernel-startup-mode-selectorwhich showed me that while indeed I have a 64-bit processor, apparently I
have only a 32-bit kernel. I tried the trick of holding down 6+4 and rebooting, but I guess that only works for 10.6 and higher. Anyway, I cannot use the 64-bit kernel apparently.So I purged iraf, and loaded up the 32-bit version. No problem. So apparently the i386 was right after all, and must've referred to the kernel, while the Core Duo 2 designation of 64-bit referred to the processor. Since iraf works, that's my story and I'm sticking to it.The only issue will likely be my imfort programs, which may fail because of the 32 vs. 64 bit issue. But I will try your trick of compiling them with 32-bit, e.g. xc -/m32 -h interpo.f -limfort -lsys -lvops -loswhich worked when I had some problems with 2.14. Thanks for doing all of this. I hope IRAF continues to have institutional support. A lot of us have a great deal of time invested in it, and I'd hate to have to learn how to do everything over with IDL.Pat Hartigan

[quote:e69d034f31]
It installed ok, but then when I tried to run it I got dyld: unknown required load command 0x80000022 [/quote:e69d034f31]The macintel binaries were built on 10.6, this is just complaining that the older 10.5 libs are incompatbile.
[quote:e69d034f31]
The only issue will likely be my imfort programs, which may fail because of the 32 vs. 64 bit issue. But I will try your trick of compiling them with 32-bit, e.g. xc -/m32 -h interpo.f -limfort -lsys -lvops -los
[/quote:e69d034f31]Whether you need the '-/m32' flag depends on the type of binary your system creates by default. My guess is on 10.5 on your machine this will be 32-bit and the flag isn't required, but it won't hurt either. The flag is only needed when the GCC on your system builds 64-bit by default (and you are using the 32-bit iraf libs).
which worked when I had some problems with 2.14.