iraf.net

Following the instructions in the readme file, I run into the following
errors:
System is running GNU/Linux Debian (unstable), running IRAF 2.12 with
ecl extension, under a xgterm window with a tcsh shell.
First:
--
ecl> mkpkg generic
deleting any dreg .e files left lying about in the source directories...
cannot open directory `lib'
cannot open directory `src'
done
ecl> mkpkg linux
!mkdir bin.linux
deleting any dreg .e files left lying about in the source directories...
cannot open directory `lib'
cannot open directory `src'
done
archiving and deleting generic objects... restoring archived linux
objects... no object archive found; full sysgen will be needed
--
Secondly:
Here's the last couple of lines from the 'mkpkg -p mscred' command:
--
FATAL: can't create x_mscred.o: No such file or directory
xc -Nz x_mscred.o -lmscred -lxtools -lcurfit -lgsurfit -lslalib
-lsurfit -liminterp -o xx_mscred.e
Warning: file `x_mscred.o' not found
/usr/bin/ld: cannot find -lmscred
collect2: ld returned 1 exit status
check file `x_mscred.o' into `mscbin$'
$checkin: file `x_mscred.o' not found
Warning, mkpkg line 26: error during checkin of x_mscred.o
Warning, mkpkg line 11: module `relink' not found or returned error
move `xx_mscred.e' to `mscbin$x_mscred.e'
$move: file `xx_mscred.e' not found
Warning, mkpkg line 30: error moving file xx_mscred.e
Warning, mkpkg line 12: module `install' not found or returned error
Warning, mkpkg line 11: module `update@src' not found or returned error--
among everything it seems to have problems when it creates symbolic
links to the created library and binary files.here's a few things that I could deduce:
while installing it should create symbolic links for various libraries
and binaries, here's an example:
--
#ls -l |grep lrw
lrwxrwxrwx 1 iraf iraf 18 2006-07-26 10:57 libmscred.a -> mscbin/libmscred.a
lrwxrwxrwx 1 iraf iraf 1 2006-07-26 11:04 x_mscred.o -> mscbin/x_mscred.o
#touch x_mscred.o
touch: cannot touch `x_mscred.o': No such file or directory
#mkdir mscbin
#touch x_mscred.o
#
--
So the symlinks it creates while installing (mkpkg files seem to use the
mscbin$ environment setting, that never actually gets set, so the
directories are not properly created.I have managed to compile a few of the commands and libraries, by using
various techniques to bypass this problem, so it seems to be a problem
in the mkpkg scripts and not the actual source code.Any help/repackaging of the source would be appreciated.Esko Gardner
Tuorla Observatory, Finland

Check the definition of 'mscred' in your hlib$extern.pkg file, I suspect either the path is wrong or missing the trailing '/' and so the package environment isn't being loaded correctly. Note that if you don't define mscred in the extern.pkg file the only other valid place is your .cshrc file (or .bashrc), it
will not be found for compilation if you declare it in the login.cl.-Mike

[quote:1babe2906b="fitz"]Check the definition of 'mscred' in your hlib$extern.pkg file, I suspect either the path is wrong or missing the trailing '/' and so the package environment isn't being loaded correctly. Note that if you don't define mscred in the extern.pkg file the only other valid place is your .cshrc file (or .bashrc), it
will not be found for compilation if you declare it in the login.cl.
[/quote:1babe2906b]it's defined, since the command 'cd mscred$' works.

That's not an adequate test. MKPKG and the mscred environment will build paths from the definition of 'mscred' and something like a missing '/' will make these invalid. Do you see errors at the top of the spool like "cannot open '/path/mscredlib/zzsetenv.def'" (note the 'mscredlib' and not 'mscred/lib')??-Mike

[quote="fitz"]That's not an adequate test. MKPKG and the mscred environment will build paths from the definition of 'mscred' and something like a missing '/' will make these invalid. Do you see errors at the top of the spool like "cannot open '/path/mscredlib/zzsetenv.def'" (note the 'mscredlib' and not 'mscred/lib')??

[quote:7ef4c19144]
Well, from the top of the log, I can find the following lines:Warning, mkpkg line 0: cannot open `mscred$lib/mkpkg.inc'
check out file `libmscred.a = mscbin/libmscred.a'warning: library `libmscred.a' not found [/quote:7ef4c19144]The warning about a missing library is normal when building from source the first time, however the error on not finding the mkpkg.inc file is definitely not normal. Does the file exist? Is it readable and have something in it?The other peculiar thing is your earlier comment:[quote:7ef4c19144]
#ls -l |grep lrw
lrwxrwxrwx 1 iraf iraf 18 2006-07-26 10:57 libmscred.a -> mscbin/libmscred.a
lrwxrwxrwx 1 iraf iraf 1 2006-07-26 11:04 x_mscred.o -> mscbin/x_mscred.o
[/quote:7ef4c19144]When binaries are installed they are put to "mscbin$x_foo.e" and such, referring to "mscbin/" should never be done and implies an environment problem. The lib/src directories (i.e. $DIRS) are not created but should exist and be populated and be readable. Can you figure out why these apparently cannot be opened? Is it possible the mscred source tarball was corrupted an unpacked incompletely?-Mike

[quote:f806bba4bf="fitz"][quote:f806bba4bf]
Well, from the top of the log, I can find the following lines:Warning, mkpkg line 0: cannot open `mscred$lib/mkpkg.inc'
check out file `libmscred.a = mscbin/libmscred.a'warning: library `libmscred.a' not found [/quote:f806bba4bf]The warning about a missing library is normal when building from source the first time, however the error on not finding the mkpkg.inc file is definitely not normal. Does the file exist? Is it readable and have something in it?-rw-rw-r-- 1 iraf iraf 374 Jan 31 2002 mkpkg.inc
(and stuff does exist inside)The other peculiar thing is your earlier comment:[quote:f806bba4bf]
#ls -l |grep lrw
lrwxrwxrwx 1 iraf iraf 18 2006-07-26 10:57 libmscred.a -> mscbin/libmscred.a
lrwxrwxrwx 1 iraf iraf 1 2006-07-26 11:04 x_mscred.o -> mscbin/x_mscred.o
[/quote:f806bba4bf]When binaries are installed they are put to "mscbin$x_foo.e" and such, referring to "mscbin/" should never be done and implies an environment problem. The lib/src directories (i.e. $DIRS) are not created but should exist and be populated and be readable. Can you figure out why these apparently cannot be opened? Is it possible the mscred source tarball was corrupted an unpacked incompletely?
[/quote:f806bba4bf]
the lib/src directories exist, the essential problem seems that when mkpkg calls the [i:f806bba4bf]!$(hlib)/mkfloat.csh linux -d $(DIRS)[/i:f806bba4bf] command in the mkpkg file, the mkfloat csh script does something evil and dies. I've run the [i:f806bba4bf]echo -n \
"deleting any dreg .e files left lying about in the source directories... "
rmbin -n -o .a .o .e .E $DIRS > $TFL; grep '\.[eE]$' $TFL | tee _.e_files
rm -f `cat _.e_files` _.e_files; grep -v '\.[eE]$' $TFL > $DFL; rm $TFL
echo "done"[/i:f806bba4bf] section of the mkfloat.csh command manually, replacing the required environment variables with the correct strings.Is this error reproducable in anybody else's linux systems?
I assume that it has compiled previously without any trouble.

The mkfloat script may possibly die if the 'bin' is a directory and not a symbolic link, e.g. such as when a source tree is copied with 'cp' rather than with 'tar'. It certainly shouldn't do anything evil and has been used reliably many thousands of times for all kinds of packages on all kinds of systems. The script will read your .cshrc file, perhaps you have some conflicting environment definition (e.g. $ARCH or a different $iraf)?-Mike

[quote:710825846d="fitz"]The mkfloat script may possibly die if the 'bin' is a directory and not a symbolic link, e.g. such as when a source tree is copied with 'cp' rather than with 'tar'. It certainly shouldn't do anything evil and has been used reliably many thousands of times for all kinds of packages on all kinds of systems. The script will read your .cshrc file, perhaps you have some conflicting environment definition (e.g. $ARCH or a different $iraf)?[/quote:710825846d]The $ARCH and $iraf definitions should be ok, the error messages, for the directories, come from the rmbin command, which should go through and remove all the extra binaries sitting around, so one can compile a clean copy.

ok, there must be something interesting going on.I tested compiling it on my laptop, through cygwin, everything seems to go ok. Besides that the cywin ARCH is missing from most (all) mkpkg files, one part of the mscred code does not compile, which then leads to another part not compiling. The combine library from the ccdred module does not compile, which probably leads to the x_finder.e binary not compiling.Otherwise the install process was easy and painless (although I don't remember anyone mentioning that you also need fitsutil and tables installed).This must lead to the fact that there's something inherently wrong (or just outdated) in the handling of the files under iraf. (And/or debian).eskog

Are you running the V2.12 you got from the stock iraf.noao.edu site, or the Debian-package version? The latter is known to be broken in a number of ways and I'd suggest upgrading.-Mike

[quote:1cb9ff00c8="fitz"]Are you running the V2.12 you got from the stock iraf.noao.edu site, or the Debian-package version? The latter is known to be broken in a number of ways and I'd suggest upgrading.
[/quote:1cb9ff00c8]Iraf, in debian, is in an oldstable distribution, so I'm running the patched ecl enhanced V2.12 .

Debian folks can call it 'stable' if they like, but any/all of the debian package versions of IRAF have had "issues" introduced by maintainers determined to "fix" this antiquated system. The ECL addon doesn't matter in the compilation of packages. If you don't want to upgrade iraf, at least consider a binary install of mscred.-Mike

[quote:9b1d5a4e74="fitz"]Debian folks can call it 'stable' if they like, but any/all of the debian package versions of IRAF have had "issues" introduced by maintainers determined to "fix" this antiquated system. The ECL addon doesn't matter in the compilation of packages. If you don't want to upgrade iraf, at least consider a binary install of mscred.
[/quote:9b1d5a4e74]
The oldstable is not available now, hasn't been for about a year. As I said I was using unstable, and the package has been removed.Wait, there' s a binary package for linux available?E.

Install 'redhat' binaries in a 'bin.linux' directory....I'm hoping the final V2.13 release will just be an integrated 'linux' for all platforms, for now redhat binaries work on most systems.-Mike

[quote:11c02401ce="fitz"]Install 'redhat' binaries in a 'bin.linux' directory....I'm hoping the final V2.13 release will just be an integrated 'linux' for all platforms, for now redhat binaries work on most systems.
[/quote:11c02401ce]
I'll give it a shot, and get back on Monday to see how it worked.

I copied over the binaries, and started to compile fitsutil, as it requires it.
Lo and behold, the compilation of fitsutil fails just as spectacularly as mscred did.
I decided it was time for some drastic action. I commandeered a poor ancient SUSE 9.1 machine, and it worked there fine (except for one thing, get back to you about that later), compiling mscred,fitsutil and tables fine.Now, the one interesting fact about this is that there's no problem with IRAF and a significantly old linux distribution. Another interesting fact, is that the combine library and x_finder.e files are not compiled correctly, as was the case in my cygwin installation.My next step is to find a debian stable or ubuntu dapper linux machine, and see if it runs into similar problems.