[daip] AIPS on new laptop; resolved?

[Eric Greisen]

Bill Junor wrote:
> Eric.
> 
>    Well, as you say, AIPS has been installed on thousands of
>    machines.  I've installed AIPS many times on a variety of
>    machines --- with success.  That is, until this installation
>    last week.
> 
>    So, rather than prevail upon you to help with the installation on
>    this new, 64-bit, dual core machine, I rolled up my sleeves.  I
>    had been concerned initially about debugging the extensive
>    installation scripts --- but I think the issue is simpler than
>    this. My computer configuration is at the bottom of this message.
> 
>    I believe that I have a working version now.  Thanks for your help
>    with the non-Intel compiler directives.
> 
>                                                Bill
> 
> ************************************************************************
> 
> Issue 1: FILAIP fails to populate DA00.
> 
>    FILAIP chokes when there is a call to ZFRE2 --- specifically
>    at the test (below) just next to "/* Fails?  Zero out stuff */".
>    Since vtemptr is a pointer only, I don't see how this can be an array
>    element.  Admittedly, I am an occasional C programmer, but if I
>    replace the test with
> 
>              (vtemptr == 0)
> 
>    then all is well and FILAIP does its stuff.  "getcmd" returns a null
>    pointer if the environment variable does not exist.  This is NULL
>    or 0 but comparing vtemptr[0] to this doesn't make sense to me.
>    Perhaps it works in some versions in some platforms?
> 
> 
> *************************************************************************
> Code snippet from ZFRE2.C ...
> 
>                                         /* strings for volnames       */
>    char cmd[10], vlist[35][80], *vtemptr;
> 
>    ..............
> 
> 
> {
>                                         /* # bytes per AIPS-byte      */
>    extern int Z_nbpab;
>                                         /* loop variables             */
>    int i, j, k, l;
>    off_t tot_user_blocks;
>                                         /* length of DA0n names       */
>    int vtemplen[35], vmaxlen, istat;
>                                         /* strings for volnames       */
>    char cmd[10], vlist[35][80], *vtemptr;
>    static char hexc[37] = "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ";
>                                         /* filesys. status structure  */
>    struct statfs *buf;
>    float xm;
> /*--------------------------------------------------------------------*/
> 
>   if ((buf = (struct statfs *) calloc (1, sizeof(struct statfs))) == 0) {
>     perror ("ZFRE2 : can't allocate memory");
>                                         /* Is this right? */
>     return;
>   }
> 
>    vmaxlen = 0;
>                                         /* For each disk */
>    for (i = 0; i < *nvol && i < 35; i++) {
>                                         /* translate the env.var */
>       sprintf (cmd, "DA0%c", hexc[i+1]);
> 
>       vtemptr = getenv(cmd);
> 
>                                         /* Fails?  Zero out stuff */
>       if (vtemptr[0] == 0) {
>          sprintf(vlist[i], "undefined %s", cmd);
>          totblk[i] = 0;
>          pctful[i] = 0.0;
>          frblks[i] = 0;
>          }
> 
> *************************************************************************
> 
> (2) readline libraries
> 
> There's something wrong with the interaction of AIPS with the readline 
> libraries on this machine as installed.  I had AIPS running but it 
> couldn't interpret any commands.  I rebuilt readline locally using 
> readline version 6.0 and linked to this.  This did not cure the
> problem. But the test programs in the readline 6.0 directory tree ran OK 
> here.
> 
> Next, I built readline with version 5.2 and linked AIPS to this.  The 
> command line interpretation works now in AIPS.
> 
> 
> 
> 
> 
> 
> ********************************************************************
> ********************************************************************
> 
> OS is RedHat Enterprise 5
> 
>    uname -a
> 
>    Linux magi.lanl.gov 2.6.18-164.6.1.el5 #1 SMP Tue Oct 27 11:28:30
>    EDT 2009 x86_64 x86_64 x86_64 GNU/Linux
> 
> -bash-3.2$ cat /proc/cpuinfo
> 
> processor       : 0
> vendor_id       : GenuineIntel
> cpu family      : 6
> model           : 23
> model name      : Intel(R) Core(TM)2 Duo CPU     T9800  @ 2.93GHz
> stepping        : 10
> cpu MHz         : 1600.000
> cache size      : 6144 KB
> physical id     : 0
> siblings        : 2
> core id         : 0
> cpu cores       : 2
> apicid          : 0
> fpu             : yes
> fpu_exception   : yes
> cpuid level     : 13
> wp              : yes
> flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge 
> mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall 
> nx lm constant_tsc ida pni monitor ds_cpl vmx smx est tm2 ssse3 cx16 
> xtpr sse4_1 lahf_lm
> bogomips        : 5850.58
> clflush size    : 64
> cache_alignment : 64
> address sizes   : 36 bits physical, 48 bits virtual
> power management:
> 
> processor       : 1
> vendor_id       : GenuineIntel
> cpu family      : 6
> model           : 23
> model name      : Intel(R) Core(TM)2 Duo CPU     T9800  @ 2.93GHz
> stepping        : 10
> cpu MHz         : 1600.000
> cache size      : 6144 KB
> physical id     : 0
> siblings        : 2
> core id         : 1
> cpu cores       : 2
> apicid          : 1
> fpu             : yes
> fpu_exception   : yes
> cpuid level     : 13
> wp              : yes
> flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge 
> mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall 
> nx lm constant_tsc ida pni monitor ds_cpl vmx smx est tm2 ssse3 cx16 
> xtpr sse4_1 lahf_lm
> bogomips        : 5850.42
> clflush size    : 64
> cache_alignment : 64
> address sizes   : 36 bits physical, 48 bits virtual
> power management:

I do not know about the readline issue but I suspect you are right about 
ZFRE2 being incorrect C.  I have changed it and the MNJ will bring the 
change over (in a few places only - relink all may wait for 31DEC10.
It is amazing that many OSes and compilers have made working code of 
this but that an older compiler on a new OS does not.

Thanks for being persistent

Eric Greisen