iraf.net

Hi Mike,I'm wondering how to specify a location other than /usr/include for iraf.h when compiling? I tried adding the following to hlib/mkpkg.inc, but I still get "iraf.h: No such file or directory" when building external packages: $set CFLAGS = "-I$(iraf)/../../include"Is there some way like this to build IRAF packages without having to create a link in /usr/include as root?Thanks!James.PS. At the top of this forum, there is a sticky message, "V2.13 Beta-2 Now Available". Is it time to unstick that?

Hi James,Which package is this and what file is failing to compile? For the most part the <iraf.h> is needed only when compiling the IRAF kernel and things like the CL/ECL or LIBC. For applications, the usual need is to define the '-Inolibc' and '-H' flags to compile a C host program. These flags are usually added in the package mkpkg file rather than system-wide, note you would modify the XFLAGS (not CFLAGS) since XC should be used to compile even .c sources. Lastly, if you need to pass a flag through to the host compilers (e.g. '-foo') and don't want XC to try to interpret it, the trick is to pass is a '-/foo' where the '/' acts as an escape.Cheers,
-MikeP.S. I unsticky-ied the post, thanks 8-)

Hi Mike,Thanks for the helpful info. The errors come up when compiling STSDAS, for example. We recompile our external packages because in the past we've had problems with Gemini package dependencies that just go away when you recompile everything from source on the same platform (usually it's not too difficult for the most important packages, so that's how we maintain them with a few scripts).Here I'm setting up our IRAF installation on a new server that doesn't already have /usr/lib/include -- but I also have to support this installation on a significant number of client machines that I don't have root access for, so it would be great to find a way of avoiding installing iraf.h and imtoolrc as root (I think the latter is just an environment variable, isn't it?). I'll try setting XFLAGS with or without an escape and see if that helps.Thanks again,James.

An alternative location for the imtoolrc is $HOME/.imtoolrc, but each user would have to set this up themselves. XImtool searches a number of likely paths (inc /iraf/iraf/dev/imtoolrc), not sure whether DS9 uses only the /usr/local/lib and $HOME or if it tries to be clever as well.-Mike

I believe that DS9 obeys $IMTOOLRC, like ximtool. We have to set this variable when using the gemini package, otherwise the imtool crashes if an imtoolrc with the larger GMOS buffer definitions is not found.James.

It looks like it is working with the escape (adding the following to hlib$mkpkg.inc)!
[quote:0b7a0394c9]$set XFLAGS = "$(XFLAGS) -/I$(iraf)../../include"[/quote:0b7a0394c9]
... at least once I copied iraf.h to my local include directory from hlib/libc/ instead of hlib/ ! Duh.So I *think* I'm root-free James.

Ah...
Editing mkpkg.inc as above made everything build as normal, but then when I actually start the CL I repeatedly get:
[quote:b434db0b7d]os.zgtenv: cannot open `/usr/include/iraf.h'[/quote:b434db0b7d]
Can you think of any way to avoid that without recompiling IRAF itself?Thanks,James.

[quote:ff7449ae96]Can you think of any way to avoid that without recompiling IRAF itself? [/quote:ff7449ae96]Define $iraf in your environment. The other paths this file supplies are $tmp (i.e. /tmp/) and $host (i.e. $iraf/unix/), otherwise it is used when building the iraf kernel or anytime iraf networking in invoked (i.e. the 'node!'). For iraf networking, the /usr/include location is hardwired unless you rebuild the system.-Mike[/quote]

Excellent! Thanks. I already had $iraf and $host defined, but not $tmp. Setting $tmp made the error go away. Actually, I can get them by doing "source irafuser.csh", so maybe it was a silly question (I have a feeling I've solved that before, sorry).I don't know much about IRAF networking, but I seem to remember at the AURA meeting it sounded like some people were doing useful things with it. I suppose if that crops up I'll need to revisit this.James.

Hi Mike,I've just discovered that setting the XFLAGS as described in this post works fine on macppc (10.4) but not on macintel (10.5 / 10.6) ... I get the error:[code:1:c7a9f60505]
os.zgtenv: cannot open `/usr/include/iraf.h'
[/code:1:c7a9f60505]Do you know if I need to set any additional flags so that iraf can look in a different path for iraf.h for macintel?Thanks,Emma

The location of the <iraf.h> file is not platform dependent, the only reason it would work on PPC but not macintel is if the IRAFARCH were set incorrectly or the hlib$mkpkg.inc file put it in the wrong place. In v2.15 an alternative for /usr/include is $HOME/.iraf which is defined globally, otherwise you need the XFLAGS (or XC_XFLAGS environment variable) to add the -I flag to the underlying compiler flags. Note you can also put the XFLAGS on the commandline, e.g.[code:1:c04117f874]mkpkg XFLAGS='-/I/opt/include'[/code:1:c04117f874]What path are you trying to use and how is it being set?

The location of the <iraf.h> file is not platform dependent, the only reason it would work on PPC but not macintel is if the IRAFARCH were set incorrectly or the hlib$mkpkg.inc file put it in the wrong place. In v2.15 an alternative for /usr/include is $HOME/.iraf which is defined globally, otherwise you need the XFLAGS (or XC_XFLAGS environment variable) to add the -I flag to the underlying compiler flags. Note you can also put the XFLAGS on the commandline, e.g.
[code:1:53903aa794]mkpkg XFLAGS='-/I/opt/include'[/code:1:53903aa794]
What path are you trying to use and how is it being set?

Hi Mike,The iraf.h link is located in /my/path/to/include/ and points to /my/path/to/iraf/iraf/unix/hlib/libc/iraf.h.My IRAFARCH is set to macintel, which I believe is correct (uname -m = i368).I have set XFLAGS to include /my/path/to/include/ in mkpkg.inc, but it doesn't seem to be looking in there, since it complains that it can't find /usr/include/iraf.h.I tried using "mkpkg XFLAGS='-/I/my/path/to/include'" but I still got the same error.In v2.15, how do you globally define $HOME/.iraf as an alternative to /usr/include?Thanks for your help!Emma

[quote:03b33b2561]The iraf.h link is located in /my/path/to/include/ and points to /my/path/to/iraf/iraf/unix/hlib/libc/iraf.h. [/quote:03b33b2561]Unless you are compiling the iraf kernel (or some select C interfaces), this file is only used by applications to get the $iraf, $tmp and $host paths, You can always just define $iraf and $tmp in your .cshrc environment to avoid the error message and path problem.[quote:03b33b2561]
My IRAFARCH is set to macintel, which I believe is correct (uname -m = i368).[/quote:03b33b2561]For pre-v2.15 systems only. In v2.15 the 32-bit intel binary is now part of the 'macosx' universal (ppc+intel) architecture and 'macintel' refers to 64-bit Intel only. [quote:03b33b2561]
In v2.15, how do you globally define $HOME/.iraf as an alternative to /usr/include?
[/quote:03b33b2561]It is defined in the hlib$irafuser.csh file, but only for the iraf kernel flags. Since I doubt you're building the system from source you normally wouldn't need this file for applications code, and at runtime its used for getting the $iraf root dir if it isn't found in the environment. Note that certain external packages shouldn't be linked against v2.15 since they haven't been ported to 64-bit yet (although a build on 32-bit systems would probably work fine).

Argh! Sorry Mike, I missed the command in the iraf user's .cshrc on the macppc machine that sourced a file that set up $iraf, $host and $tmp ... I've set that up similarly on the macintel machine and now it works ... sorry about that!Thanks!Emma