[daip] AIPS - compiling custom tasks pain

[Eric Greisen]

Michael Bietenholz wrote:
> Hi Eric - not sure if you're the person to ask about this, but here goes:
> 
> I just tried compiling aips on a brand-new 64-bit Unbuntu 11.04 system
> with gcc and gfortran 4.5.2.  This is likely folly, I know :-) but I
> need the capability of modifying & compiling the occasional aips task.
> Details as to what is going wrong (and how to get part of the way
> there) are below.  However, a much easier workaround for my needs
> would be this - would it be possible for me to get an account at NRAO,
> where I could put my code, compile it (using ifort etc) and then
> retrieve the .EXE and run it on my machine from a binary-distribution
> AIPS?  I realize this is probably a bit of a grey area regarding the
> ifort license, but it seems worth asking.
> 

I have forwarded this request to the helpdesk to see if they are 
willing.  They should be.  The machine that compiles 64-bit Linux is 
rishi.  Login and dot /home/AIPS/LOGIN.SH (bash) or source 
/home/LOGIN.CSH (tcsh) and the environment will be set.

>           cheers,       michael b
> 
> As to the issues with compiling AIPS, I found this
> 
> 1) you need to change both the compilers and the compiler options in
> the install script.  The compiler options (at least CCOMOPT) have the
> distinction that they do NOT get read in from the .AIPSRC file, so you
> have to specify them again each time you re-run install.pl (the
> compilers themselves do get remembered).  I used " " for CCOMOPT (ie,
> nothing), and edited $SYSLOCAL/CCOPTS.SH by hand.  Note that in
> install.pl, if you say "CCOMOPT" and then just hit return, it reverts
> to the previous version, you need to hit "space"-return.

The latter I understand - a simple carriage retrun is a NULL and 
install.pl ignores it.  The former - not reading CCOMOPT I have trouble 
believing.  I can tell it read it on my personal installation since it 
refers to 31DEC09 for the -I part which matches my old .AIPSRC file.
It might have trouble with a totally blank value field.
> 
> 2) I think one needs to edit $SYSLOCAL/CCOPTS.SH to have these
> switches for gcc.  (It doesn't find includes w/o the $INC, and
> withouth the HAVE_LINUX_GLIBC it tries to include bsd/sgtty.h and
> fails, since this file, even if installed, is buried under /usr/lib on
> modern systems)
> 
>   COMP="-c -I$INC -DHAVE_LINUX_GLIBC"
> 
My file actually has rather more:
  -c -O3 -fomit-frame-pointer -funroll-loops 
-I/home/primate/AIPS/31DEC09/INC -D_FILE_OFFSET_BITS=64 -DHAVE_LINUX_GLIBC

> 3) the XAS Makefile retains the -axWPT option for 64-bit gcc's, which
> doesn't work, so it needs to be manually edited (I think this is
> independent of the CCOPTS.SH etc)

yes - XAS Makefile has always been a problem...and will depend on the 
compiler without any good way to change things

> 
> AIPSCC    : Interpret  AIPSCC  \
> AIPSCC    :            /home/aips/31DEC11/LNX64/PREP/ZWINC2.c
> AIPSCC    : as         LIST=FALSE PURGE=TRUE
> AIPSCC    : plus       /usr/bin/gcc  \
> AIPSCC    :            /home/aips/31DEC11/LNX64/PREP/ZWINC2.c
> /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.5.2/../../../crt1.o: In 
> function `_start':
> (.text+0x20): undefined reference to `main'
> collect2: ld returned 1 exit status
> AIPSCC    : Compile of /home/aips/31DEC11/LNX64/PREP/ZWINC
> 
> 4) after above fixes, it gets through INSTEP2, but dies in INSTEP4
> with
> 
> /home/aips/31DEC11/LNX64/PREP/PRTAB.f: In function ‘prtbdo’:
> /home/aips/31DEC11/LNX64/PREP/PRTAB.f:430:0: internal compiler error: 
> Segmentation fault
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See <file:///usr/share/doc/gcc-4.5/README.Bugs> for instructions.
> FC        : Compile of /home/aips/31DEC11/LNX64/PREP/PRTAB.f
> FC        : ends with fatal error(s)!
> 
>      1:      PROGRAM PRTAB
>      2:C------------------------
> ....
>    428: 1040 FORMAT ('ERROR',I5,' OPENING OUTPUT DEVICE')
>    429:      END
>    430:      SUBROUTINE PRTBDO (IRET)
>    
> 431:C----------------------------------------------------------------------- 
> 
>    432:C   PRTBDO reads, formats, and prints a table extension file
>    433:C   Output:
>    434:C      IRET   I   Error code:
> 

This I do not understand.  I had something like it recently which was 
due to my naming 2 subroutines with the same name.  PRTAB does not have 
this problem.  What compiler version are you using?  Many gfortrans have 
had problems.

Eric Greisen