iraf.net

Hello, I'm trying to install IRAF with Redhat EL 4 X64. I figured that I would
have to rebuild the binaries from scratch for this architecture. I've
tried this with x11iraf and get the following error messages after typing
mkpkg redhat
make World >& spool &I have attached the spool file from this attempt. Please let me know if
you are working on generating a 64 bit version of these files. Thank you.Sincerely,
Brent Buckalew

Hi Brent,IRAF is not 64-bit compatible and a build from (current) sources won't help. The existing 32-bit binaries will run, and provided you have all the 32-bit compatibility libraries installed it's possible on some systems to add a '-m32' flag to compile, but in most cases compilation is not supported either. Binaries for external packages can be found on this site or we can provide them if needed. Note, files on a 64-bit filesystem can also be an issue since the system might not 'see' the file. A user in Japan has had some success on a 64-bit port (see http://www.ir.isas.jaxa.jp/~cyamauch/iraf64/) but it doesn't look like a complete system just yet.That aside, your build problems with X11IRAF are unrelated to 64-bit problems. The X11IRAF v1.5 sources from the download area should compile, but there's not much to be gained by a 64-bit binary of xgterm/ximtool so again I'd recommend using the existing binaries.Cheers,
-Mike

Hi Fitz,Why is there no 64-bit IRAF set? Your "and an build from (current) sources won't help" is cryptic, but intruiging.I've been asked to install IRAF on a 64-bit computing cluster and I'm running into all kinds of headaches, partly due to the mixed nature of the install.Ihe IRAF install sequence seems as if it could be improved by bringing it more into line with more standard install procedures (.configure builds, rpm installs, etc. etc.) I should probably know better than to offer this, but I would even be willing to help provide support for such an effort. -Keith

[quote:546eec50d4]Why is there no 64-bit IRAF set? Your "and an build from (current) sources won't help" is cryptic, but intruiging.[/quote:546eec50d4]The IRAF sources define SZ_INT and SZ_POINTER to both be 4 bytes, in a 64-bit system this would obviously have to be changed in a number of places but this is primarily why building from the current sources won't work. Moreover, the iraf kernel code is not 64-bit clean and various data structure and usage in application need to be examined closely to have a working system. Chisato has made a good start on this and we'll likely start a 64-bit port early next year, for now you're stuck using 32-bit binaries with no workaround to build on a 64-bit system (e.g. external packages).[quote:546eec50d4]I've been asked to install IRAF on a 64-bit computing cluster and I'm running into all kinds of headaches, partly due to the mixed nature of the install.[/quote:546eec50d4]I'm not sure what you mean by 'mixed nature', if you have a specific problem we could probably help.[quote:546eec50d4]Ihe IRAF install sequence seems as if it could be improved by bringing it more into line with more standard install procedures (.configure builds, rpm installs, etc. etc.) I should probably know better than to offer this, but I would even be willing to help provide support for such an effort.[/quote:546eec50d4]Autoconf, RPM, deb packages, OSX dmg files, ....it never ends. Some of these are already available on the web but the plan here is to release a network-install script to take care of the details for most users and keep the distribution to the same tarball format. Various people have posted their install crib sheets or made packages, but the last page of the installation guide has a complete example of the steps involved.-Mike

Hi Mike, Thanks for your response.[quote:c41b33ff7a]Autoconf, RPM, deb packages, OSX dmg files, ....it never ends. [/quote:c41b33ff7a]Out of hand dismissal of standardized systems seems a little hasty, to me. Many of these packages already have (semi-)automated solutions for solving things like the SZ_* def problems you cite above. Why not go where the code is (apologies to Sutton) instead of rolling your own from scratch? I get the sense that some of the problem is climbing lots of learning curves on a budget and schedule that are already obligated to lots of other things. There are many though, who know these packages and could build them fairly quickly if enlisted.So my real question is, why can't the entire IRAF source be made available? Or maybe its all in as.*.gen and I just don't know it?---By "mixed nature", I mean the requirement to install some source and some things precompiled with stuff already built. As one example, the IRAF binaries hard code some /usr/... directory paths into them. On our cluster (and I imagine other systems), this can be a problem because there are local stripped down /usr directories on a per-node basis, and installed libraries like IRAF go somewhere else. It's been a long time since I ran into another package that had precompiled absolute paths in it.I hope all this doesn't seem critical - I don't mean to be. IRAF is a really impressive software suite and I'm just wondering why a little bit more of an open-source approach wouldn't make it better.Cheers, Keith

[quote:be147d2181]Out of hand dismissal of standardized systems seems a little hasty, to me. Many of these packages already have (semi-)automated solutions for solving things like the SZ_* def problems you cite above. Why not go where the code is (apologies to Sutton) instead of rolling your own from scratch?[/quote:be147d2181]Assuming mine was an out-of-hand statement also seems hasty. The points is, yes I know there are standard package tools (and the associated dependency hell that sometimes goes along with it), and I fully endorse anyone wanting to put these together. However, *I* don't want to spend time maintaining a half dozen distribution formats and so these aren't a priority (for me). None of these tools will solve the 64-bit problem automatically. [quote:be147d2181]So my real question is, why can't the entire IRAF source be made available? Or maybe its all in as.*.gen and I just don't know it?[/quote:be147d2181]The as.*.gen tarball IS the entire source distribution.---[quote:be147d2181]By "mixed nature", I mean the requirement to install some source and some things precompiled with stuff already built. As one example, the IRAF binaries hard code some /usr/... directory paths into them.[/quote:be147d2181]The only hardwired path is /usr/include/iraf.h which can be ignored if missing so long as the environment can define some values when needed (i.e. $iraf, $tmp, and $host (this is $iraf/unix/)). Otherwise /usr is typically a default for the installation but you can unpack the system anywhere and install the command wherever you like. Even the requirement for an 'iraf' user is only a convenience. See for example https://iraf.net/faqman/index.php?op=view&t=129 and https://iraf.net/phpBB2/viewtopic.php?t=76110&highlight=jyang[quote:be147d2181]I hope all this doesn't seem critical - I don't mean to be. IRAF is a really impressive software suite and I'm just wondering why a little bit more of an open-source approach wouldn't make it better. [/quote:be147d2181]'Open source' means taking the source (which you have) and feeding back any improvements you make to the community, not just doing it the way everyone else in linux did it. Live the dream...Cheers,
-Mike

Ok. If I have all the source, I'll take a look.I think /usr/lib/include/imtoolsrc is also hardwired.How does one resubmit changes/updates?
Is there a CVS or SVN location?
Are there unit tests anywhere?Thanks for your help.-Keith

The imtoolrc file is only used by the display servers (XImtool and DS9) but again if these are in $HOME/.imtoolrc instead of /usr/local/lib/imtoolrc they will be found and no /usr touching is required.There's no CVS or SVN, just post a note or a URL with any changes you made and why. All changes to the core system are vetted and only then merged into the code, no guarantees that everything gets in but there's also no rule you can't put it in your own rpm.-Mike

[quote:b3cc51e07a="fitz"]However, *I* don't want to spend time maintaining a half dozen distribution formats and so these aren't a priority (for me). [/quote:b3cc51e07a]Well, you don't have to. Other people will package your software according to the specifications of the different operating systems and their flavors. For example, I'm currently trying to get x11iraf into fedora linux and I must say that having a more standard build system (autotools for example) would help a lot.

It's nice to hear that others are interest in an autotools build for iraf.I spent some time on Friday looking at this, and while it's not a trivial modification, I think I can shed some light on what it's likely to take. Since this thread started out with a focus on a 64-bit version of IRAF, I'll start a new thread on "IRAF and autotools" in a little bit. -Keith