problem with running external packages on V2.16

[massey]

I did a clean install of V2.16 on my MacBook Pro yesterday, the 64-bit version (i.e., binaries going into bin.macintel). I then did a ./configure and a make stsdas to lead on the stsdas package. All appeared normal. I can load packages (i.e., stsdas, hst_calib, sits) but when I go to execute a command like "x1d" I get the following error message:

stis> x1d ob150204_crj.fits output=test.p1d.fits a2center=515 extrsize=6

!/iraf/iraf/extern/stsdas/bin.macintel/cs6.e 'ob150204_crj.fits' 'test.p1d.fits' -t -v -back -cte -disp -hel -flux -c 515. -x 6. -bm -bo 3 -a unweighted
/iraf/iraf/extern/stsdas/bin.macintel/cs6.e: Command not found.

And, indeed, there is no /iraf/iraf/extern/stsdas/bin.macintel directory, only a /iraf/iraf/extern/stsdas/bin.macosx directory (which does contain cs6.e)

[fitz]

The problem is that the X1D task explicitly builds a path to the cs6.e binary (presumably this is done elsewhere as well) using the 'stsdasbin$' logical path (which in turn uses the 'arch' variable, which is macintel for 64-bit systems), this is then executed as a shell escape. In contrast, tasks declared using the normal 'task' mechanism go through a sort of search path in the CL that looks first in the current architecture binary directory, and then in an 'alternate' binary directory (e.g. 'macosx' if 'macintel' isn't found). This allows packages like STSDAS that can't run 64-bit to still be used (Note that pyraf does not implement this path mechanism).

To fix this particular problem, you'll need to make the stsdas$bin.macintel directory a symlink pointing to stsdas$bin.macosx so the binary will be found either way, e.g.

[massey]

Okay, thanks! I should have thought of that fix myself; I just assumed there was some fundamental configuration issue wrong. This problem must surprise a lot of users...