On Thu, 7 Aug 2003, Tim Jenness wrote:

> JAC are purchasing a Mac OS X machine for testing (since we are getting
> more and more requests for Mac support). As part of this Brad will be
> putting the Starlink classic system onto it. Has anyone done this yet?
> Who should we talk to? Obviously, if classic was in CVS this would be
> simplified enormously and Brad would be able to put the Mac patches into
> the repository (so that everyone would benefit). Has any progress been
> made on CVS?

Hi Tim (and all),

time to confess that I was approached at a seriously weak moment by a
local GAIA and OSX fan, and have looked at this a bit (but never offering
even the chance of a proper port by Starlink I hasten to add)... I was
also half persuaded by the fact that OSX is clearly gaining acceptance as
a good place to be if you need windows-like functionality, but like (or
need) UNIX as the underlying system (the actual number of people who've
asked me about this I can still count on the fingers of one hand, so
genuine critical mass is someway off).

The bad news is that this will not be a 2 day port (not even at Al's
speed), it took me that long just to compile some of the infrastructure
and GAIA (using a slash and burn technique, nothing pretty or very useful
in code terms). In summary I'd say this is very much more like a port to
new flavour of UNIX, rather than another Linux/Solaris and estimate
there's at least 2 months of activity to do properly.

How did I do this. I got my local chap to pop his laptop up on the
network, install some packages from fink (notably g77) and ssh'd in. So,
yes it uses the XFree86 server (someone asked?). Try that under Windows.

I've attached the notes I made during the compilation to this message. The
worst problem is the lack of proper case-sensitivity of HFS and the early
GCC 3 compiler available (this problem may of course go away, as would the
case-sensitivity issues, if I could work out how to cross-compile for
OSX).

The current state of this work is stopped, my user went off on
holidays/conference and I haven't had a chance to see how well GAIA
survived some real work that he planned. If it's OK I intend to make an
unsupported tarball available.

Cheers,

Peter.




OS X porting notes.



   Time: couple of long days.. Time to do this properly for USSC

   2 months I'd guess.



   Case sensitivity. The partitions provide case sensitivity in a

   limited sense, files with the same sequence of characters are

   the same file, even though they look different (i.e. WCS.h is the

   same file as wcs.h). Skycat is full of these and we cannot do 

   

      ln -s ems_par EMS_PAR



   as this links the same file (a "mv" is OK). For Skycat I had to

   rename some files (but not the classes). Building the combined 

   libraries (libskycat.a) was also tricky as the repeated .o names

   were present the in the .objs files (picked up during configure).



   Compiler/linker issues. Used gcc 3.1, which is a bit early (3.2 is

   known to be better). AST needed "-g" to work around formatting

   issues in the FITS channel (7.1234567E-7 came out as 7. .1234567E-7!). 

   Sometimes when linking the symbol _f__lioproc wasn't found, still

   don't know why. Since this was just needed for parts of CONVERT and

   KAPPA that I didn't need it was passed by. Repeated "-o" flags are

   an error for ld. Problem when linking all ATASKS as this is used

   through our makefiles. The isnan() function couldn't be seen, just 

   the internal __isnan() form.



   Ranlib. Worth a section of it's own. When you copy or move 

   a libxxx.a file you need to re-run ranlib. Caused major problems

   in GKS which incrementally builds the .a library and moves in

   around. Also you can not put anything but .o files in a library

   and expect ranlib to work. Some packages mix in plain files (by

   accident).



   HDS. File mapping didn't work (failed during unmap), although I

   expect it could be made to work with effort (BSD kernel).



   PSX. No cuserid on system, used "getlogin()" instead. There

   were problems (compiler I presume) with the scope of the psxtmstr 

   struct, just worked around this using a void pointer.



   GKS. The terminal handling is different (termios instead of termio)

   didn't need this so commented out. See ranlib for more. Note the

   the C-preprocessor needed -traditional-cpp to work.



   MSP. mknod needs superuser privilege on OS X so it fails to make

   fifos. Replaced with call to mkfifo.



   DTASK. Signals are different in "OS X" need a proper implementation

   (dts_setsig is currently a dummy).



   IMG. Needed the -traditional-cpp flag.



   Shared libraries. Didn't attempt these.



   CONVERT. The _f__lioproc problem (looked like it might just apply

   to SPECX) and lack of IRAF and FIGARO libraries means this is down

   a lot of convertors. FITS2NDF is all that GAIA requires. 



   

   GAIA: doesn't seem to track down relative softlinks (crash in contour

   toolbox). Casts like (AstFitsChan *) in StarRtdImage.C and StarWCS

   are broken all over the place (must be a compiler issue, these are

   OK for gcc 3.2 under Linux). Skycat has loads of files with "same

   name" according to "OS X", g77Fortran need some help too (couldn't

   recognise the system). Niggles with things like "struct semun_ds" 

   including <malloc.h> , <values.h> (doesn't exist), type of

   sockaddr_in  etc. (usual problems with really new UNIX).





   KAPPA: only kappa_mon linked (need ARDMASK only, rest showed the 

   _f_lioproc unresolved symbol).



   EXTRACTOR: as cheating by using the ix86_Linux system needed to 

   correct the BSWAP (ppc bigendian).