Urania

Scisoft OSX Intel 2008.9.1 was released yesterday. Nor noted in his blog post about it that this is a bug fix release that

should resolve a few outstanding problems created when changing the location of scisoft from /scisoft to /Applications/scisoft/. Packages such as MIDAS and Gnuplot should now work properly.

This version removes some remaining dependencies on the HPC OSX compilers, which I had on my machine but which most users do not have (and do not want to have).

I compared the /Application/scisoft/i386/Packages directory from this release of Scisoft OSX to the last one and there are no new packages installed. The few issues I noted with the Scisoft OSX 2008.8.1 release all appear to still be valid. Notably:

1. Permission Problems Persist: When the installer installs /Applications/scisoft, it appears that a bug in Apple’s Installer program triggers a change in ownership of the /Applications directory to that of the second user on the system. I strongly suggest checking the ownership of the /Applications directory afterward and if isn’t owned by an administrative user, set it as such using:
   

   sudo chown username:admin /Applications
   

   
   (where “username” is the primary administrative users username, in most cases, your username) to perform the repair.
2. ds9 command line executable missing: This release has the same glitch I noticed in version 2008.8.1 in that /Applications/scisoft/i386/bin doesn’t appear to have a ds9 binary installed. You can fix this by installing the X11 version of ds9 there or by linking to the Aqua version of ds9 that was installed using the command line
   

   ln -s "/Applications/scisoft/i386/Applications/SAOImage DS9.app/Contents/MacOS/ds9" /Applications/scisoft/i386/bin/ds9

I have placed a copy of this release in my Scisoft OSX Mirror in case the main Scisoft OSX repository gets bogged down.

[The hack reported here for getting FreeType compiled under MacPorts in a fully Leopard-compatible way is no longer necessary as current versions of MacPorts properly handle this now.]

As I reported on my blog here, here, and here, I have been having problems with my PHP programs on my web server that use fonts crashing with errors of the form:

The process has forked and you cannot use this CoreFoundation functionality safely. You MUST exec().
Break on __THE_PROCESS_HAS_FORKED_AND_YOU_CANNOT_USE_THIS_COREFOUNDATION_FUNCTIONALITY___YOU_MUST_EXEC__() to debug.

The problem turns out to not lie in PHP, but in Apple’s pre-installed FreeType which is compiled with “old font” support. This old font support is apparently old Carbon code instead of Cocoa (if I understand correctly, which I may not) and thus requires a forking of the process… which triggers this fault.

If you use MacPorts version of Apache and PHP (as I am now doing), you can fix this problem by editing the Portfile for freetype to disable old font support, recompiling it, and restarting your apache server. So following the hints in the MacPorts Bug Report #15909 I did the following:

Edit the Portfile located at /opt/local/var/macports/sources/rsync.macports.org/release/ports/print/freetype/Portfile changing line 50 to

#    --with-old-mac-fonts 
--with-fsspec=no --with-fsref=no --with-quickdraw-toolbox=no --with-quickdraw-carbon=no 

Now recompile freetype in MacPorts. To do this you have to force the uninstallation of freetype (which will cause much gnashing of teeth by MacPorts since freetype is required for several other ports.

sudo port -f uninstall freetype

Then recompile and reinstall freetype:

sudo port install freetype

And finally, give the apache server used by MacPorts a fresh restart to get it going with the new freetype libraries loaded.

sudo /opt/local/etc/LaunchDaemons/org.macports.apache2/apache2.wrapper restart

Doing this fixed all my freetype issues and I was able to use my FinderChart program again. The only disadvantage is that if freetype is updated from version 2.3.7 in MacPorts (and no no-old-font variant appears), I will have to re-apply this hack.