iraf.net

Hi,This is my first time posting on iraf.net, I hope that I'm posting this question in the appropriate place.I downloaded iraf.lnux.x86.gz from https://iraf.net/downloads/ yesterday, installed IRAF v2.15 (with 32-bit Linux binaries) on my redhat machine and then installed the external packages using the following commands:

./configure
make stsdas tables

However, when I try to load tables (from PyRAF), I get the following error:

--> tables

****WARNING: outdated parameter file, please: unlearn stwfits
Traceback (innermost last):
File "<CL script CL1>", line 1, in <module>
iraf.tables(_save=1)
File "<CL script clpackage.tables>", line 31, in tables
iraf.cl(Stdin='tables$load.cl')
File "<string>", line 1, in <module>
File "<CL script CL2>", line 12, in string_proc
File "<CL script tables.fitsio>", line 28, in fitsio
if (iraf.strfits.getParObject('template').p_value == ''):
IrafError: Cannot find executable for task strfits
Tried /iraf/iraf/extern/tables/bin.linux/x_fitsio.e,
/iraf/iraf/extern/tables/pkg/fitsio/x_fitsio.e

I noticed that in the tables directory, bin points to bin.generic, but there is nothing in bin.generic. All the binaries are in bin.redhat and there is no bin.linux directory. The x_fitsio.e binary is in bin.redhat. Also, my IRAFARCH is set to linux. I also noticed in the ftp://iraf.noao.edu/iraf/v215/v215revs.txt file it says, "IRAF v2.15 is very forgiving in the way that is allows multiple architectures to be used. For example, where the core system architecture might be 'linux64', external packages containing only the 32-bit 'linux' or older 'redhat' bin directories will be used automatically when a native 'linux64' binary cannot be found." Can I assume that would be the same when using IRAF with 32-bit Linux binaries?Please could you tell me where I am going wrong?Thank you in advance for your help.

[quote:7ac8f9384d]Please could you tell me where I am going wrong?[/quote:7ac8f9384d]In all seriousness, the problem is that you are using PyRAF. The comment about IRAF v2.15 being forgiving of architecture names could be clarified to say that the v2.15 CL is what is actually looking in the alternate bin directories for workable binaries. Since you're using PyRAF you'll either have to wait for similar support in PyRAF or else move the contents of the STSDAS/TABLES bin.redhat directory to the package bin.linux directory so they will be found correctly.Since we rebuindle the tar files obtained from STScI anyway so they can be used with the dynamic package system (and to fix a problem in their distribution) it wouldn't be hard to either make a link or rebundle the binaries directly. My goal was to change as little as possible in the externally developed packages, however in the time its taken me to write this post I've made the architecture links and redeployed the packages to the repository. Do a "make stsdas" to reinstall with the links (tables will be done automatically).

I'm curious - why wouldn't Slim just set IRAFARCH to 'redhat'? Since that is where the binaries are (he said), and that is the flavor he is on, that should enable PyRAF to do the right thing.In any case, Slim, we are playing with IRAF 2.15.* here at STScI and not hitting this issue, so feel free to query help@stsci.edu as well.Chris

[quote:af261fe4d9]I'm curious - why wouldn't Slim just set IRAFARCH to 'redhat'? Since that is where the binaries are (he said), and that is the flavor he is on, that should enable PyRAF to do the right thing.[/quote:af261fe4d9]Because the IRAF binaries are in the 'linux' architecture, and unless Pyraf is smart enough to discover that 'redhat' binaries don't exist but 'linux' binaries do so use those instead, users are left with either creating links in the external packages to resolve the archs (as we did in repackaging stsdas) or creating the links in the core system. The CL is happy to use a core 'linux' arch and packages containing 'redhat' or 'suse' or even 'linux64' is that is all that is available.[/quote]

It sounded from the user like redhat binaries did exist...[quote:4f397d7d78]
All the binaries are in bin.redhat and there is no bin.linux directory.
[/quote:4f397d7d78]Would these binaries (in bin.redhat), not be for redhat?

The problem is that Pyraf is building a path to the binaries based on IRAFARCH or somesuch. So a default v2.15 32-bit system would be looking in 'bin.linux' for the core system and external packages. Resetting IRAFARCH (or somesuch) might redirect this path to find the stsdas$bin.redhat binaries, but would then break finding the core system libs.When the CL creates the path to the binaries when executing a task it looks for alternate architectures if the binary cannot be found, pyraf needs to implement the same thing or else stsdas/table need to be re-released to support the v2.15 architecture names (since neither is available at this point, we've repackaged both packages to fix this issue and make it compatible with the dynamic package scheme).

[quote:9cdf001437="fitz"]
When the CL creates the path to the binaries when executing a task it looks for alternate architectures if the binary cannot be found, pyraf needs to implement the same thing or else stsdas/table need to be re-released to support the v2.15 architecture names (since neither is available at this point, we've repackaged both packages to fix this issue and make it compatible with the dynamic package scheme).[/quote:9cdf001437]What do we need to do to the STSDAS package? The binaries STScI is distributing worked just fine with my IRAF 2.15, so it is unclear to me what the problem is.

Are you sure you're comparing apples correctly? This is from pyraf and not the CL, and with a task specific to TABLES like 'strfits' and not just any TABLES task (like 'tdump' which is also now included in the core IRAF system NTTOOLS package).Both v3.13 packages have bin.linux and bin.redhat directories, if users install binaries in bin.redhat but the native arch is 'linux' then pyraf won't find them. Either bin.linux or bin.redhat needs to be made a symlink so that in either case the links resolve to the binary directory. Note there is a similar issue with macintel/macosx.
While we're at it: The stsdas v3.13 binary distro for redhat contains an extra 'bin.redhat' directory with old binaries, and despite the name it isn't really a compressed file.

[quote:41a79a2dd2="fitz"]Are you sure you're comparing apples correctly? This is from pyraf and not the CL, and with a task specific to TABLES like 'strfits' and not just any TABLES task (like 'tdump' which is also now included in the core IRAF system NTTOOLS package).
[/quote:41a79a2dd2]I'm not entirely sure. I ran 2.15 for a while over the summer and around the time of the release, but I never installed it for general use. Since it has been a while, I don't remember the details. My basic aliveness test loads stsdas and tables then runs iminfo, listarea, imtab, tstat, tprint, prow, sgraph, implot, and imexam. The procedure is defined for both CL and pyraf. I usually use pyraf, but I can't say for sure what I was using at the time.I would likely have installed the stsdas/tables binaries with
[code:1:41a79a2dd2]
cd stsdas/bin.$IRAFARCH
tar xf ...
cd ../../tables/bin.$IRAFARCH
tar xf ...
[/code:1:41a79a2dd2]
That would have put my binaries in bin.linux if IRAFARCH is set to linux. If I understand the issue correctly, that could explain why I didn't see a problem.[quote:41a79a2dd2]
Both v3.13 packages have bin.linux and bin.redhat directories, if users install binaries in bin.redhat but the native arch is 'linux' then pyraf won't find them. Either bin.linux or bin.redhat needs to be made a symlink so that in either case the links resolve to the binary directory. Note there is a similar issue with macintel/macosx.
[/quote:41a79a2dd2]So, you changed the IRAFARCH for Red Hat Enterprise from "redhat" to "linux", and you can hide the change from the users by making bin.redhat a symlink to bin.linux.[quote:41a79a2dd2]While we're at it: The stsdas v3.13 binary distro for redhat contains an extra 'bin.redhat' directory with old binaries, and despite the name it isn't really a compressed file.[/quote:41a79a2dd2]I knew the file wasn't compressed from a user report, but I didn't notice the bin.redhat/bin.redhat directory. Thanks for pointing it out.

[quote:670c033eac]So, you changed the IRAFARCH for Red Hat Enterprise from "redhat" to "linux", and you can hide the change from the users by making bin.redhat a symlink to bin.linux. [/quote:670c033eac]Not quite: What we did was to consolidate [b:670c033eac]all[/b:670c033eac] 32-bit Linux systems into a single 'linux' architecture name, deprecating the use of the 'redhat' arch (the 'suse' arch was removed earlier). In order to avoid [b:670c033eac]requiring[/b:670c033eac] external packages to create the symlink or change the binary dir and re-release, the CL was modified to look first in the IRAFARCH dir, and then if no binary were found to look in "alternate" directories that would also work on that system (e.g. in bin.redhat on an IRAFARCH=linux system). The same was applied to the OSX architectures and e.g. the 'linux64' system which could also easily run 32-bit binaries.This means that packages like STSDAS which aren't capable of 64-bit or updated for the new arch names could continue to be used [b:670c033eac]without requiring a change[/b:670c033eac] from the way you distribute them.
PyRAF users, however, would require the symlink or instructions that the stsdas-bin.redhat distribution be unpacked in 'bin.linux' for v2.15 systems. Since we repackage stsdas/tables to work with the v2.15 dynamic package scheme I just added the symlink to resolve the bin dirs (otherwise it is completely unmodified from your distro).