[daip] AIPS on new laptop; resolved?
Bill Junor
bjunor at lanl.gov
Thu Nov 12 09:47:38 EST 2009
Hi Eric.
Well, I am always reluctant to mess with code which seems to have
been working quite well all this time! I am also so rusty on the fairly
involved AIPS installation scripts that I mess with these with some
trepidation. But this was a useful exercise for me also since I'll need
to port AIPS to yet another machine in a few days.
Bill
Eric Greisen wrote:
> 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
>
More information about the Daip
mailing list