iraf.net

I've just installed IRAF using the latest STScI Astroconda on a Ubuntu 16.04 system:

conda config --add channels http://ssb.stsci.edu/astroconda
conda create -n iraf27 python=2.7 stsci pyraf iraf

and it works apart from "xc". If I run it with no arguments I see this sort of thing:

/home/phase2operator/miniconda2/envs/iraf27/iraf/lib/libex.a(imgetl.o): In function `imgetl_':
/srv/ureka.iraf/ur_work/iraf/sys/imio/db/imgetl.x:25: undefined reference to `i_dnnt'
/home/phase2operator/miniconda2/envs/iraf27/iraf/lib/libex.a(wfmer.o): In function `wfmerv_':
/srv/ureka.iraf/ur_work/iraf/sys/mwcs/wfmer.x:511: undefined reference to `d_mod'

where the missing references are all in libf2c.a, which isn't being linked in for some reason. If I do "xc -v", I see that the COLLECT_GCC_OPTIONS are very similar to a working "xc" that I have from a Ureka installation on another machine, except that libf2c.a is not included.

I suspect that there is an environment variable problem somewhere, but I can't for the life of me work it out! Any clues?

Regards, Michael

The Astroconda distribution from STScI has it's own custom IRAF version and environment, so in general you should contact them (help@stsci.edu) if you continue to have problems after this post.

The XC compiler builds the compiler/linker commands by relying on several environment variables, e.g. $iraf, $IRAFARCH, $host, $hbin. Typically you would source the $iraf/unix/hlib/irafuser.csh (or irafuser.sh) script to define the full environment needed for development, however 1) the values in this file are edited by the iraf install script which may be fixed for astroconda or not changed from the default at all, or 2) astroconda may have some other way of defining the environment. Check the values of these variables in your environment to see if they are set, and if not source the irafuser.csh file to set them.

Additionally, some systems or users may reset the variables 'host' or 'MACH' for some other reason and this will interfere with the path creation as well. The 'host' definition should be the expanded path to '$iraf/unix/' while 'MACH" should be 'linux' (32-bit) or 'linux64' (64-bit). And finally, I notice there is a "/src/ureka.iraf/....." path in the error messages -- Is this where astroconda installed the files or is it possible you have an earlier Ureka install on the machine that may be confusing things? Does a "which xc" show you running the XC command from the astroconda system?

Hi Mike (you are a legend by the way, thanks for continuing to support IRAF!),

The /sys/ureka.iraf stuff is baked into the Anaconda distribution from STScI, and is not a remnant from a previous installation of mine (I tried this on a fresh Ubuntu 16.04). There isn't a /sys/ureka.iraf directory that I can see. "which sc" shows that I am using the Anaconda distribution.

I have asked STScI for help, but nothing back yet. I expect that compiling SPP code is a dying art. I really do appreciate the historical reasoning behind SPP - it was remarkable for its time.

I will look more closely at the environment variables.

Thanks again.

Regards, Michael

I've got xc to work by copying libf2c.a from the unix/bin.linux/ directory into unix/hlib/.

I *think* the problem is related to the iraf.sh file that STScI uses to define environment variables. hlib is missing. Also, I note that unix/hlib/libc/iraf.h is full of references to the original build of IRAF at STScI, not to my own environment as it is with a Ureka installation of IRAF.

I put some debugging code into xc.c, and tracked the problem down to the call to "mkfname" to find the full path for "-lf2c". This calls "iraflib", which in turn calls "os_sysfile", and it is this that fails to find libf2c.a. I can't immediately see how os_sysfile decides where to look, and whether this can be dynamically altered by setting environment variables.

Two things to check:

1) if the $HSI_CF environment variable is set, does in include a "-DSTANDALONE" flag. If not, then
2) does the file iraf$unix/boot/bootlib/ossysfile.c have the "#define STANDALONE" uncommented?

My guess is that this STANDALONE option is what's causing that path to resolve to 'host$hlib' instead of one of the binary directories. This would make sense given the local build paths you see in the error messages and an improperly built kernel.

What I can't explain is why you don't see similar errors about not finding the libos.a in the same directory as libf2c.a. Or, do you?

(1) HSI_CF does NOT include -DSTANDALONE. Here it is:

HSI_CF="-I/home/phase2operator/miniconda2/envs/iraf27/iraf//include -O -DLINUX -DREDHAT -DPOSIX -DSYSV -w -m32 -Wunused"

(2) ossysfile.c has #define STANDALONE commented out, i.e.,

/* #define STANDALONE */

I think the reason I don't see a problem with libos.a is that there are multiple copies of it, e.g., in unix/bin.linux, in unix/hlib, and in unix/os.

Hello,

As you can see, the current AstroConda IRAF package is basically a dump of what was in Ureka, but instead of configuring the environment with Ureka's ur_setup function, it has some variable definitions in etc/conda/activate.d/iraf.sh. I think this must be a problem with the latter environment setup. From a quick comparison, it looks like it's missing "hlib=$iraf/unix/hlib/" for some reason. Does that make any difference? Anyway, we (Gemini) are hoping to release a new AstroConda IRAF package with STScI in the very near future and I would hope that this problem will go away then.

Cheers,

James.

Hi James,

Thanks for your reply. Yes, I saw the missing hlib definition, but it doesn't help to add it - there is more to it than that. I also had a look at ur_setup, but it rapidly got rather complicated.

That is great news that Gemini is working with STScI on a new release. I'm not sure what else (besides xc) is broken in the current distribution.

Cheers, Michael

I've got a version of IRAF that builds on a Ubuntu 16.04 system. It's available at github.com/steelewool/iraf-v216 and the branch oleboleUpdates is the one working. The branch was made by forking from github.com/iraf/iraf-v216 and then applying the PRs made to the iraf repository. the master on iraf doesn't have all of the necessary updates for the code to build. But, the branch I referenced does indeed build libf2c.a.

---

Rob Steele (Robert.D.Steele@jpl.nasa.gov)