A thing called "mkpkg" is the engine that handles all of this, so it may be useful to look at its documentation.
IRAF package building is heavily tied to the csh. In short, to build IRAF packages, your login shell must be csh. In my case, I use the "tcsh" and this works fine.
If you are like me and have a nice bash environment set up with command completion and vi style keystroke editing, you will go mildly crazy running the csh, but that is the price you have to pay. No doubt tcsh could be tuned as well -- and maybe you want to look into this if you intend to make iraf package building your career.
You may read that it is possible to use bash, but this is simply not true. I spent days chasing weird errors having to do with the propogation of environment variables, and it just is not worth any more time. Forget about building under bash. What I do is set up a special user dedicated to building IRAF packages that I call "irafdude" and make his login shell tcsh and this solved all my problems.
While you are setting this up, if you are like me and habitually use "vi" keystrokes to edit your command history, you should add this line to your .cshrc to avoid going insane:
bindkey -vWhile you are at it, put all the following into your .cshrc so you will be ready for package building (see below).
setenv iraf /iraf/iraf/ setenv IRAFARCH linux setenv mirror /iraf/iraf/extern/mirror/ source /iraf/iraf/unix/hlib/irafuser.csh
Note the /iraf/iraf/ path. If your IRAF does not live there, you should make it so before going any further with this. (If it doesn't, whoever installed it was clueless and/or was not following instructions).
You probably don't care, but the root of the problem is that the iraf build system makes heavy use of aliases. These get propogated to child processes by the csh, but not necessarily by bash. When I tried to use bash, I got all kinds of terrible problems, even runaway process generation recursion that locked up my system and required a reboot. It does not get much worse than that.
cd /iraf/iraf/extern mkdir mirror cd mirror tar xvf /home/tom/mirror.tarThe starting point is thusly the SPARC package we currently use on the old suns.
setenv iraf /iraf/iraf/ setenv IRAFARCH linux setenv mirror /iraf/iraf/extern/mirror/ source /iraf/iraf/unix/hlib/irafuser.csh
dnf install glibc.i686 dnf install glibc-devel.i686 dnf install ncurses-compat-libs.i686When I was missing libraries, and tried to run mkpkg, I got messages like the following:
$ mkpkg -p mirror linux /iraf/iraf/unix/bin.linux/mkpkg.e: No such file or directoryHowever, the file mkpkg.e exists and is executable. What is going on?
You must do this inside of the IRAF tree as shown below. One more tricky, fussy IRAF thing.
cd /iraf/iraf/extern/mirror mkpkg -p mirror linux mkpkg -p mirror >& spool mkpkg -p mirror summaryThe game is to look at "spool" to make sure there are no errors.
su cd /iraf/iraf/extern chown -R irafdude .You only have to do the above once. Then do this:
su - irafdude cd /iraf/iraf/extern/mirror mkpkg -p mirror linux mkpkg -p mirror >& spool mkpkg -p mirror summaryAmazingly, all of this still works on my Fedora 29 system.
Sat May 25 08:26:37 MST 2019 Subdirectory src/oven/menusc is up to date Subdirectory src/oven/menusm is up to date Subdirectory src/ovenr is up to date Subdirectory src/odisp is up to date Subdirectory src/ograph is up to date Subdirectory src/xytran is up to date Subdirectory src/imagemask is up to date Subdirectory src/smooth is up to date Subdirectory src/util is up to date ranlib libpkg.a Updated 1 files in libpkg.a Object x_mirror.o is up to date move `xx_mirror.e' to `mirrorbin$x_mirror.e' purge directory `mirrorbin$' !date Sat May 25 08:26:37 MST 2019
Tom's home page / [email protected]