iraf.net

Hi Neil,
We've suggested the binary emulation to others who've asked about
Alpha/Linux but haven't heard back from anyone either way so I can't say
whether it works or not. Chances for a native IRAF Alpha/Linux port are slim at this
point. The problem is that the IRAF kernel is not 64-bit clean and much
mucking about needs to be done so the file descriptors, memory pointers,
etc all still work on a 64-bit system. We get away with this on the Tru64
systems by using the '-taso' flag on the compiler to produce 32-bit
binaries, however GCC provides no such alternative (at least not last time
I looked). There hasn't been much demand for an Alpha/Linux port so we're
not likely to do one specifically, however the 64-bit upgrades are needed
anyway and they would make a compile-from-source effort much easier.
That's still a ways off and doing to work yourself is probably more than
you bargained for. Hope this helps, let us know if you still have questions.Regards,
Mike Fitzpatrick

>From clifford@astro.ox.ac.uk Fri Feb 21 05:03:54 2003
Date: Fri, 21 Feb 2003 12:03:46 +0000
From: Neil Clifford <clifford@astro.ox.ac.uk>
To: Mike Fitzpatrick <fitz@noao.edu>
Cc: sites@tucana.tuc.noao.edu
Subject: Re: Alpha/Linux IRAF?On Thu, Feb 20, 2003 at 03:50:39PM -0700, Mike Fitzpatrick wrote:> We've suggested the binary emulation to others who've asked about
> Alpha/Linux but haven't heard back from anyone either way so I can't say
> whether it works or not.Hi. I think I will try it shortly and will report back.> Chances for a native IRAF Alpha/Linux port are slim at this
> point. The problem is that the IRAF kernel is not 64-bit clean and much
> mucking about needs to be done so the file descriptors, memory pointers,
> etc all still work on a 64-bit system. We get away with this on the Tru64
> systems by using the '-taso' flag on the compiler to produce 32-bit
> binaries, however GCC provides no such alternative (at least not last timeIt occurs to me that it might be possible to do similar with the native
alphalinux compilers that DEC/Compaq/HP provide free. I'll also have a
look at this and let you know what happens.cheers,--
Neil Clifford * Astrophysics Computer Manager * clifford@astro.ox.ac.uk>From fitz Fri Feb 21 08:56:13 2003
To: clifford@astro.ox.ac.uk
Subject: Re: Alpha/Linux IRAF?Hi Neil,> It occurs to me that it might be possible to do similar with the native
> alphalinux compilers that DEC/Compaq/HP provide free. I'll also have a
> look at this and let you know what happens. Last time I checked, from the Compaq Fortran for Linux Alpha
release notes: the -xtaso feature of Tru64 UNIX cc and the -taso
feature of Tru64 UNIX ld are not supported on Linux
so addresses are always 64-bit valuesSo it looks like a native 64-bit HSI is still required. If you find
something new please let me know.Cheers,
-Mike

On Thu, Feb 20, 2003 at 03:50:39PM -0700, Mike Fitzpatrick wrote:> not likely to do one specifically, however the 64-bit upgrades are needed
> anyway and they would make a compile-from-source effort much easier.
> That's still a ways off and doing to work yourself is probably more than
> you bargained for.Hi Mike. A little research suggests problems will arise anyway due to
Linux/Alpha glibc being 64bit only. I guess eventually you have to look
at a 64bit clean IRAF port as we look forward to moving to ia64 but in
the meantime I'll experiment with DUNX running under alpha binary
emulation. cheers,--
Neil Clifford * Astrophysics Computer Manager * clifford@astro.ox.ac.uk

>From clifford@astro.ox.ac.uk Thu Feb 27 11:15:41 2003
From: Neil Clifford <clifford@astro.ox.ac.uk>
To: Mike Fitzpatrick <fitz@noao.edu>
Subject: Re: Alpha/Linux IRAF?
References: <200302211556.h1LFuC519822@tucana.tuc.noao.edu>Hi Mike. Well I have tried running IRAF (DUNX 2.11.2) under AlphaLinux
(2.2.20 kernel) with COFF emulation and I get:ntc@alnair:~/iraf$ mkiraf
-- creating a new uparm directory
Terminal types: xgterm,xterm,gterm,vt640,vt100,etc. (xgterm recommended)
Enter terminal type: xgtermA new LOGIN.CL file has been created in the current directory.
You may wish to review and edit this file to change the defaults.
Image display devices have been created OKntc@alnair:~/iraf$ strace -f cl
execve("/usr/local/bin/cl", ["cl"], [/* 15 vars */]) = 0
--- SIGCHLD (Child exited) ---
SYS_0(0x1200b3208, 0x1200b3ac8, 0x1200b3108, 0, 0 <unfinished ...>
--- SIGSEGV (Segmentation fault) ---
ERROR (501, "segmentation violation")
in newpfile: parhead exceeds topd
Fatal startup error. CL dies.
ntc@alnair:~/iraf$ Any ideas (not that I'm expecting any support really!).--
Neil Clifford * Astrophysics Computer Manager * clifford@astro.ox.ac.uk>From fitz Thu Feb 27 12:51:32 2003
To: clifford@astro.ox.ac.uk
Subject: Re: Alpha/Linux IRAF?Hi Neil,
I've never even logged into an Alpha/Linux system so I'm not sure
how much help I can be. I did notice though that your MKIRAF output
included:> A new LOGIN.CL file has been created in the current directory.
> You may wish to review and edit this file to change the defaults.
> Image display devices have been created OKThat last line is not part of the normal script output, was this a custom
script or is that your comment which just landed in an unfortunate spot on
the page?
Also, th e/usr/local/bin/cl command is installed as a symlink to
a C-shell script ($iraf/unix/hlib/cl.csh), are you sure the '-f' flag to
strace is handling this as a real child process? You can try executing
the binary directly but you'll need to have the proper environment
defined, i.e. % setenv iraf /iraf/iraf/ <-- trailing '/' required
% setenv IRAFARCH redhat <-- ...or is it 'alpha'?
% setenv arch .redhat <-- ...or ".alpha"
% strace -f $iraf/bin.redhat/cl.e <-- to run the binary directlyThe various startup scripts do some checking to determine the platform
type, mostly using the 'uname' command. Since you installed the DUNX/IRAF
release you should probably have installed the Alpha binaries in 'bin.redhat'
directories. Note also that DUNX/IRAF uses an iraf shared library 'libiraf.so'
which needs to be in your LD_LIBRARY_PATH to be picked up correctly.
Lastly, did you really install V2.11.2 and not V2.12? If so this
could just be a Y2K problem since that wasn't fully fixed until V2.11.3,
does temporarily resetting the system clock to 1999 change anything? In
any case, you'll want to try to get this working with V2.12 to avoid at
least the Y2K stuff.
Hope this helps.Cheers,
-Mike

>From clifford@astro.ox.ac.uk Fri Feb 28 07:54:21 2003
Date: Fri, 28 Feb 2003 14:54:14 +0000
From: Neil Clifford <clifford@astro.ox.ac.uk>
To: Mike Fitzpatrick <fitz@noao.edu>
Subject: Re: Alpha/Linux IRAF?Hi Mike. I followed your advice and tried it with a 2.11.2 DUNX version.
It still won't play. The same error under strace and running under gdb I
havealnair:~/iraf> /usr/bin/gdb /iraf/iraf//bin.alpha/cl.e
GNU gdb 2002-04-01-cvs
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for
details.
This GDB was configured as "alpha-linux"...
(gdb) run
Starting program: /usr/iraf/irafbin/bin.alpha/cl.e
warning: Cannot insert breakpoint -3:
Cannot access memory at address 0x3ff8005f990
(gdb) I guess it just doesn't want to play (maybe some 32 v. 64 bit [g]libc
issue)? Annoying - I can get the Tru64 IDL binaries to run! Maybe that
is totally 64bit clean now. I don't know.--
Neil Clifford * Astrophysics Computer Manager * clifford@astro.ox.ac.uk>From fitz Fri Feb 28 14:08:30 2003
To: clifford@astro.ox.ac.uk
Subject: Re: Alpha/Linux IRAF?Hi Neill,> Cannot access memory at address 0x3ff8005f990 Certainly looks like a 64-bit address problem, probably from the
dynamic libc as you suggest. If you're up for one more experiment, I've
put a statically linked 'hello world' program up at ftp://iraf.noao.edu/pub/hello.e.ALPHA_STATICCould you try downloading this in binary mode, reset the execute permissions
and then just run it as % ./hello.e helloIf it works it may mean that statically linked IRAF binaries will work, if
not then it's probably not worth pursuing and further.Cheers,
-Mike

>From clifford@astro.ox.ac.uk Sun Mar 2 17:16:50 2003
Date: Mon, 3 Mar 2003 00:16:47 +0000
From: Neil Clifford <clifford@astro.ox.ac.uk>
To: Mike Fitzpatrick <fitz@noao.edu>
Subject: Re: Alpha/Linux IRAF?On Fri, Feb 28, 2003 at 02:08:28PM -0700, Mike Fitzpatrick wrote:> % ./hello.e hello
>
> If it works it may mean that statically linked IRAF binaries will work, if
> not then it's probably not worth pursuing and further.Hi Mike. It works fine. If you can afford the time to build a statically
linked DUNX IRAF version (or can brief me on cooking one up for myself)
I'd be more than happy to try it out. cheers,--
Neil Clifford * Astrophysics Computer Manager * clifford@astro.ox.ac.uk>From fitz Mon Mar 3 16:15:46 2003
To: clifford@astro.ox.ac.uk
Subject: Re: Alpha/Linux IRAF?
Cc: fitzHi Neill,
Good to hear. I recompiled the system so everything is linked
statically and hopefully will work just as well. The files you need are ftp://iraf.noao.edu/pub/fitz/alpha_linux/hs.lnux.alp.gz
ftp://iraf.noao.edu/pub/fitz/alpha_linux/ib.lnux.alp.gz
ftp://iraf.noao.edu/pub/fitz/alpha_linux/ib.lnux.alp.gzDownload everything in binary mods and unpack in the following directories: ib.lnux.alp.gz -----> $iraf/bin.alpha
nb.lnux.alp.gz -----> $iraf/noao/bin.alpha
hs.lnux.alp.gz -----> $iraf/unix/bin.alphaDo this *after* you've unpacked the standard as.dunx.gen.Z file, this is
especially important so the new HSI binaries in $iraf/unix/bin.alpha get
replaced with the statically linked ones (these include things like the
graphics translators used for hardcopy).
The only other concern I have is whether things like the install
script, $hlib/mkiraf.csh or $hlib/cl.csh will work correctly under Alpha
Linux since they use 'uname' to check the architecture. Presumably this
already works but if you end up with a system not finding binaries these
may need to be tweaked a bit. I doubt you'll be able to use the system
for compilation of external packages but I can build those here if needed.
We won't be able to track down segfaults or other things which show up
on this platform so it's all as-is. If you get it all working I'd appreciate it if you let me know
some details of your setup (e.g. where you got the COFF emulation, system
installed the "normal" way or did you rename directories, etc) so I can
put together a readme file for others who may want to try this. We've had
a number of inquiries over the years but you're the first to actually follow
through and try that hello.e example! Hope this helps.Cheers,
-Mike

>From clifford@astro.ox.ac.uk Tue Mar 4 09:51:44 2003
Date: Tue, 4 Mar 2003 16:51:41 +0000
From: Neil Clifford <clifford@astro.ox.ac.uk>
To: Mike Fitzpatrick <fitz@noao.edu>
Subject: Re: Alpha/Linux IRAF?On Mon, Mar 03, 2003 at 04:15:45PM -0700, Mike Fitzpatrick wrote:> If you get it all working I'd appreciate it if you let me knowHi Mike. Thanks for taking the time to do that build but sadly it
doesn't look like it wants to play!alnair:~/iraf> ldd $iraf/bin.alpha/cl.e
not a dynamic executable
alnair:~/iraf> strace -f $iraf/bin.alpha/cl.e
execve("/iraf/iraf//bin.alpha/cl.e", ["/iraf/iraf//bin.alpha/cl.e"], [/*
24 vars */]) = 0
--- SIGSEGV (Segmentation fault) ---
ERROR (501, "segmentation violation")
in newpfile: parhead exceeds topd
Fatal startup error. CL dies.
alnair:~/iraf> /usr/bin/gdb /iraf/iraf//bin.alpha/cl.e
GNU gdb 2002-04-01-cvs
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "alpha-linux"...
(gdb) run
Starting program: /usr/iraf/irafbin/bin.alpha/cl.e
warning: (Internal error: pc 0x12082b74 in read in psymtab, but not in symtab.)
Program received signal SIGSEGV, Segmentation fault.
compile (opcode=44, args=536868024, args2=302084240) at compile.c:91
91 compile.c: No such file or directory.
in compile.c
(gdb) backtrace
#0 compile (opcode=44, args=536868024, args2=302084240) at compile.c:91
warning: (Internal error: pc 0x12082b70 in read in psymtab, but not in symtab.)#1 0x1202d3f8 in login (cmd=0x140476d0 "") at main.c:413
warning: (Internal error: pc 0x12082b70 in read in psymtab, but not in symtab.)#2 0x1202c9f8 in cmain_ (prtype=0x14046db0, bkgfile=0x140472d0,
cmd=0x140476d0) at main.c:120
warning: (Internal error: pc 0x12082b70 in read in psymtab, but not in symtab.)#3 0x12029490 in onenty_ () at cl.f:151
warning: (Internal error: pc 0x12082b70 in read in psymtab, but not in symtab.)#4 0x12117048 in irafmn_ () at main.f:209
warning: (Internal error: pc 0x120830c4 in read in psymtab, but not in symtab.)warning: (Internal error: pc 0x120830c4 in read in psymtab, but not in symtab.)warning: (Internal error: pc 0x12082b70 in read in psymtab, but not in symtab.)warning: (Internal error: pc 0x120830c3 in read in psymtab, but not in symtab.)warning: (Internal error: pc 0x120830c4 in read in psymtab, but not in symtab.)#5 0x120830c4 in main () at stgoutstr.f:78
(gdb) Shame!--
Neil Clifford * Astrophysics Computer Manager * clifford@astro.ox.ac.uk>From fitz Wed Mar 5 13:34:06 2003
To: clifford@astro.ox.ac.uk
Subject: Re: Alpha/Linux IRAF?
Cc: fitzHi Neil,
That's too bad, I was hoping this would work. Anyway thanks
for trying, at least we know it's not as simple as using the emulator.Cheers,
-Mike

>From clifford@astro.ox.ac.uk Wed Mar 5 13:52:49 2003
From: Neil Clifford <clifford@astro.ox.ac.uk>
To: Mike Fitzpatrick <fitz@noao.edu>
Subject: Re: Alpha/Linux IRAF?
References: <200303052034.h25KY4013376@tucana.tuc.noao.edu>
In-Reply-To: <200303052034.h25KY4013376@tucana.tuc.noao.edu>; from fitz@noao.edu on Wed, Mar 05, 2003 at 01:34:04PM -0700On Wed, Mar 05, 2003 at 01:34:04PM -0700, Mike Fitzpatrick wrote:> That's too bad, I was hoping this would work. Anyway thanks
> for trying, at least we know it's not as simple as using the emulator.Sure. No problem. It would have been nice if it had worked but at least
we can run with x86-linux instead. cheers,--
Neil Clifford * Astrophysics Computer Manager * clifford@astro.ox.ac.uk