cl failed on MacOSX 10.6 (intel)

[jchiar]

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.macintel

I 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

[fitz]

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

[jchiar]

I downloaded the Mac OSX 64-bit file (iraf.macx.x86_64.gz).

Perhaps I made an error in setting up the directory structure?

[fitz]

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?

[drupke]

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.

[fitz]

The architecture is identified with the command

[jchiar]

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.

[fitz]

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.html

for 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.

[jstottsj]

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

[fitz]

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

[jstottsj]

[drupke]

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/HT3773

I 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.

[fitz]

[hartigan]

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 got

dyld: 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-selector

which 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 -los

which 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

[fitz]