[daip] some AIPS weird/errorneus findings

[Eric Greisen]

On 07/09/2019 03:14 AM, Marian Soida via Daip wrote:
> Hi,
> 
> I just like to share my yesterdays experience in compiling AIPS (31DEC19)
> from sources with gcc/gfortran v8.3.0 at continuously updated Gentoo Linux.

My experiments with gfortran versions 7.x and 8.x indicate that they do 
not work with AIPS.  Something bad happens with the dynamic memory 
allocation for the pseudo-array processor.  Try IMAGR in your version.

> 
> After one of updates my AIPS stopped working - complaining about missing
> libgfortran.so.3 library. This was understood as the most recent one is
> libgfortran.so.5. Since the binary installation of 31DEC19 uses the same(old)
> library, I decided to compile it from sources.
> 
WE provide libgfortran.so.3 in the $LIBR/INTELCMP directory which should 
be in your $LD_LIBRARY_PATH.

> The first wall I faced, was lack of SUN rpc stuff in glibc-2.29. I was removed
> some time ago as 'obsolete'. Fortunately Gentoo offers some work-around
> with a 'ntirpc' package - but to use it one has to add -I/usr/include/tirpc
> in the compiler command line (and -ltirc to linking options).
> However, it was not so easy - two AIPS files:
> ./APL/DEV/UNIX/ZXDRST.C
> ./APL/DEV/UNIX/ZXDRFP.C
> calling 'xdrmem_create' function. For some reason after compiling and
> storing into the library (by INSTEP2) require 'xdrmem_ncreate' function
> - note the extra 'n' in the middle.

I was not aware of these and found that they are only used by the 
program DAIP which is more than obsolete.  Therefore I removed these 2 Z 
routines from AIPS along with DAIP and 3 subroutines which were only 
used by DAIP and called the Z routines.  Thanks for pushing me to do 
this which I should have done long ago.

> I compiled both files (PP, CCOM, and COMRPL) by hand - and I ended with
> a correct library (requiring 'xdrmem_create'). What makes the difference
> between calling the same command 'by hand' and within INTSTEP2 chain - stays
> a 'magic' to me(!)

Magic to me also - note that these are compiled by install.pl not 
INSTEP2 which depends on them.  These do work from install.pl usually 
but sometimes have an issue which must be resolved before install.pl can 
compile them.
> 
> Things went smooth up to the point in INTSTEP4 where it tries to compile
> ./APL/PGM/NOTST/ATLOD.FOR
> The compiler failed at line 12186:
>           call getparm (jstat, grphdr, i_grphdr, 1, bufptr, buffer,
> complaining about 'not enough members' in 'grphdr'. I noticed, that
> in fact the 'grphdr' (and 'i_grphdr') table is declared with size of '11',
> and 'getparm' expects '640' (!). I changed the declaration to '640' (lines
> 11730, and 11729) and all went smooth on.
> 

ATLOD has a number of issues and is only needed if you have data from 
the (old) ATCA.  Usually it can be ignored.
> I just recalled one more thing - it seems to stay much longer than recent
> versions, as I faced that many years ago (and got used to that...)
> While compiling 'XAS' the Makefile forces the compiler to use '-c' option
> when it is supposed to make 'xas' executable - and it fails of course.
> I always do that step manually.

The building of the Makefile for XAS by install.pl has had this issue 
for a long time.  I have to fix it every year when I do a version roll 
over.  I will take another look at it to see if I can fix it...
> 
> I hope this can help in keeping AIPS alive...
> 
> Best regards,
> 

Thanks

Eric Greisen