 |
 |
On Tue, 24 Oct 2006, Alasdair Allan wrote: > Tim Jenness wrote: >> Alasdair Allan wrote: >>> Tim Jenness wrote: >>>> Isn't this simply because you are trying to run the starlink software >>>> using rosetta rather than using native intel? If you build the intel >>>> native starlink version from CVS (Brad did it yesterday and it doesn't >>>> take very long) won't the problems go away? >>> >>> No its because we have both Intel and PPC iMacs and the software (and >>> other software) is running on both platforms, shared from the same NFS >>> drives I think. I don't think compiling a Universal binary would help. >>> Brad told me he wasn't sure how to do this when we were at ADASS anyway? >>> >> >> Confused. If G95 endianness is set to the Intel form then g95 won't be able >> to read any of the .ifc files because they were written in ppc form. >> Starlink software will break. > > The confusion is because we're not just dealing with the Starlink software > here, we have a bundle of different stuff. One of the other applications is > setting the endianness flag so it can read its data files (which are one way > round regardless of what platform they got written on). Why would compiling > the Starlink software as a Universal binary help, surely it'll still be set > the wrong way round on one of the Intel or PPC platforms regardless at that > point? Okay. Yes it would be wrong on one of them. I think this boils down to "user beware" and "not our problem gov" and "make sure that your local software that needs the endianness set either does the conversion itself or does a PSX_PUTENV or actually just wraps its calls in a shell script that will set the correct value OR always uses the same unit number for read and sets G95_UNIT_ENDIAN_x" -- Tim Jenness JAC software http://www.jach.hawaii.edu/~timj