[daip] SU FILE problem

[Eric Greisen]

Roderick Johnstone writes:
 > Thanks for this hint. I ran the midnight job on our binary installation 
 > of 31DEC06 and we now have an aips installation that is able to reduce 
 > Robert's recent data fine.
 > 
 > However there was an error during the midnight job run which is related 
 > to some changes we have made to our computing systems. Can you advise on 
 > the following please...
 > 
 > In the past I have done all the aips installation on my desktop which 
 > used to be xpc4, so our midnight job script was called do_daily.xpc4. In 
 > the meantime I have a new system and the xpc4 address was reused for 
 > another system which is now running the x86_64 variant of the Scientific 
 > Linux 4.2 operating system that we are using on all our systems. Our 
 > 64-bit systems have (most of) the 32-bit compatibility libraries 
 > installed so generally run 32-bit apps ok.
 > 
 > So I logged into xpc4 and did a ./do_daily.xpc4. It threw an error:
 > 
 > UPDUPDATE - running make for changed XAS.SHR
 > /usr/bin/ld: cannot find -lXext
 > collect2: ld returned 1 exit status
 > make: *** [xas] Error 1
 > 
 > so I broke out of it.

     Is your MNJ really binary - in which case this compilation should
not be done.  I expect that we have an error in the MNJ code and, in
an attempt to be friendly, we compile XAS when we have already shipped
you a new binary.

 > 
 > However, in the course to trying to understand what was going on I tried 
 > to run the midnight job on another 32-bit system (xpc21) which failed 
 > because the hostname was wrong.
 > 
 > Then I ran MAKE.MNJ on xpc21 (telling the date that I installed the 
 > 31DEC06 version, as near as I could dtermine) to see if I could make a 
 > midnight job for that host (xpc21). The do_daily.xpc21 run on xpc21 
 > fails because something like ClientName (which was still xpc4) doesnt 
 > match the hostname - sorry, I can't remember the precise error message.
 > 
 > I then ran do_daily.xpc4 again on xpc4 and let it proceed to the end (it 
 > gave the same error with not being able to find -lXext, but aips seems 
 > to run and vlarun seems to reduce Robert's data fine.
 > 
 > If I do a locate libXext on xpc4, I get:
 > /usr/X11R6/lib64/libXext.so.6.4
 > /usr/X11R6/lib64/libXext.so.6
 > /usr/X11R6/lib64/libXext.so
 > /usr/X11R6/lib64/libXext.a
 > /usr/X11R6/lib/libXext.so.6.4
 > /usr/X11R6/lib/libXext.so.6
 > 
 > so the lib directory which contains the 32-bit versions of the libraries 
 > doesnt have the plain .so file without the version number. In the lib64 
 > directory this is a sym link to the .so with the version number. I guess 
 > that I could fix this by hand making the link and running do_daily.xpc4 
 > again.
 > 
 > Do I have a badly broken distribution with the -lXext error?

    If the aips TV (XAS) works then nothing is broken.  The -lXext is
needed only to make XAS.

 > 
 > If I re-run do_daily.xpc4 on xpc4 after making the symlink libXext.so in 
 > the 32-bit directory is that a good way to fix it? I can imaging other 
 > problems later though.

Don't bother unless you are compiling everythiung rather than using a
binary MNJ.

 > 
 > I think that xpc4 was set as our 'master' node ages ago so I'm wondering 
 > whether its best to continue using xpc4 as our installation node and 
 > fixing up the missing sym link or whether there will be other problems 
 > later. Alternatively, is it better to try and make a 32-bit node the 
 > master or at least the node on which I can run the midnight job. If so, 
 > how do I accomplish this?
 > 
 > What role does the 'master' node play in all this.

Not much really.  To change masters just change the name of the
do_daily.<mastername> file and edit $SYSLOCAL/UPDCONFIG to select the
new master.

Eric Greisen