The siren call of OSX is getting stronger... we will be hearing more calls to support it. And probably soon! We should at least understand more or less the load of adding another OS:

  • Maintenance of another set of extlibs
  • Keeping all the code building on another OS - sure, gcc is gcc is gcc, but it didn't always used to be the case (eg Sun had different problems from linux).
  • Running Release Manager & sorting through the results (so, load on both providing/maintaining the service and on the Release Manager person, eg Toby and Jim)
  • Running system tests
  • Documentation of everything to do with a new OS - additional branches of the workbook (where there are windows, linux now). I presume we cannot just lump OSX and linux together.
  • User support on the OS

Some random current facts:

  • SLAC/SCS does not currently support MACs, but Kavli is trying to change that
  • Kavli has a ~14 box MAC cluster in SCS that runs LSF
  • The SSC expects to have to support MAC for SciTools

The MAC cool factor is way up these days, so everyone is wanting to jump on board. What is your opinion on whether we can afford to be cool?

  • No labels

4 Comments

  1. Richard Dubois

    From Navid:

    I expect the RM load to be minmal. The logic for linux and mac would be identical so the same code should run. In theory if we can get the extlibs compiled on the MAC the RM will attempt compiles on it just like on unix.

    Mac OS x tiger comes with gcc4 as its default compiler. (at least for me since I have XCodde installd). I can easily switch between gcc3.3 and 4 with a utility provided by the OS (gcc_select).

    Since our code is running both on Windows and Linux it should be mostly standards compliant. I expect a few syntax problems since MAC (tiger) has gcc3.3.

    Fixing those shouldn't be a problem (we have to do it anyways soon). In fact, it would prepare use for when Fedora/RedHat decide to switch compilers.

    My main concern is the external libraries. We have to make sure all libraries we use run on the mac. Nowadays that shouldn't be a problem because OS X is too close to unix. Our code would require minor changes hopefully that each package maintainer should be able to take care of.

    Navid

  2. Unknown User (pln)

    Richard asked for something like a progress report on "porting" extlibs. I have only done a few, and it's been pretty straightforward.

    • CLHEP. Darwin is one of the supported platforms, so it can't really be called a port. I had to tweak the configure script so it would use g++ instead of CC (which is an alias for gcc). There's probably a tidier way to do it. We are several versions behind the state of the art. I did the latest in the 1.8 series because it claims to have a bunch of bug fixes.
    • Minuit (C++ version). This isn't one of the standard packages, but I hope it will be. There's some kind of funny problem that causes VERY slow compilation of some files with g++ 3.3 with optimization on. The gurus know about it, but not how to fix it. It seems to work OK after it compiles.
    • cppunit. I just went to version 1.10 rather than sticking with 1.9. Should I be more disciplined about this? Compilation was straightforward.
    • xerces. The compilation instructions seem rather more complex than they need to be, but Darwin is one of the Unix flavors which is described. Version 2.6.0 is the latest, so that doesn't seem to be a problem.
    • PIL. Apparently we use a non-standard version of this. I have put out feelers to find the source code, but it hasn't turned up yet.

    1. Richard Dubois

      I would suggest some discipline, since part of the exercise will be to build GR or ST as we already have it configured, ie the current set of extlibs.

  3. Unknown User (pln)

    • James Peachey sent me the source code for the PIL version that we use. He also sent instructions for compiling, so I'm not exactly a pioneer here. To get readline support it's necessary to use fink to install the readline package. That could hardly be easier.
    • More on CLHEP versions. I looked at all the requirements files in Science Tools, and there is some variety in the versions wanted. Only one wants 1.8. Others want 1.9, while most don't care.
    • Cfitsio. Version 2510 compiles with no problem. Test programs work OK. Again I'm a few versions ahead.