The big difference is that I will now be using the built-in Apache2 and PHP 5.3.0 under MacOS 10.6.1. I have gotten tired of the fact that everytime MacPorts updates it PHP installation, it tends to clobber the php.ini file for the site, requiring me to re-setup everything. Furthermore, I am also a bit tired of having MacPorts install its own version of everything I already have under MacOS X (such as Apache2, PHP, and MySQL). I understand their philosophy (and the practicality of it), but I am trying to keep my computer as clean as possible. As such, I am only using MacPorts to provide libssh2 to the SSH2 extension for PHP.

I noticed that the WordPress code had ssh2 support built-in, so all I need to is activate SSH2 support in the MacPorts installed PHP and I should be able to use SFTP in WordPress to handle the upgrades. I poked around and found this posting outlining the process for adding ssh2 support to Ubuntu. It guided me in developing this list of hints:

1. If you haven’t already, start by installing libssh2 via MacPorts using the command:
   

   sudo port install libssh2

2. Download the necessary SSH2 PHP extension using the build in PECL command
   

   sudo pecl download channel://pecl.php.net/ssh2-0.11.0

   The sudo is necessary because a lock file needs to be created during the download in /usr/lib/php, which is a protected directory. However, the file is downloaded to the current directory. Once the download is complete, we will need to unpack the SSH2 extension and go into its directory:
   

   tar xzvf ssh2-0.11.0.tgz
   cd ssh2-0.11.0

   If you try to do the normal phpize/configure/make sequence for compiling PHP extensions at this point, you will get a string of error messages ending with something like
   

   /private/var/tmp/apache_mod_php/apache_mod_php-53~1/Build/tmp/pear/download/ssh2-0.11.0/ssh2.c:1105: warning: passing argument 4 of 'add_assoc_stringl_ex' discards qualifiers from pointer target type

   
   This is occuring because there is an incompatibility between this ssh2 extension code and PHP 5.3.0. It can be patched by downloading the ssh2-php53.patch file from http://remi.fedorapeople.org/ssh2-php53.patch and applying the patch from the command line in the ssh2-0.11.0 directory
   

   curl -o ssh2-php53.patch http://remi.fedorapeople.org/ssh2-php53.patch
   patch < ssh2-patch53.patch

   Once you have done that, you can finish the SSH2 PHP extension compilation using
   

   phpize
   ./configure --with-ssh2=/opt/local
   make
   sudo make install

   The final command informed me the ssh2.so library was placed in /usr/lib/php/extensions/no-debug-non-zts-20090626/

3. Now you need to make sure PHP loads the new module, so we open the PHP configuration file /etc/php.ini and edit the extension_dir line to point the extension directory above:
   

   extension_dir = "/usr/lib/php/extensions/no-debug-non-zts-20090626/"

   
   and then add the following line to the end of the section on “Dynamic Extensions”:
   

   extension=ssh2.so

   If you edited everything properly, a simple php -v from the command line should NOT trigger any errors.

4. Finally, I restart the apache2 server so that the reconfigured PHP is loaded using
   

   sudo apachectl restart

   At this point, I checked (via the phpinfo(); command to see if the web server was supporting SSH. Near the bottom of the phpinfo(); listing is a listed of “Registered PHP Streams”. As noted here, it should incude “ssh2.shell”, “ssh2.exec”, “ssh2.tunnel”, “ssh2.scp”, and “ssh2.sftp”. If it does, you have enabled SSH support for Apache2 driven PHP pages under MacPorts.

5. If you are doing this to get WordPress 2.7 automatic installation working, you will notice now when the automatic installation dialog box pops up, in addition to ftp and ftps, you now have an ssh option.

I just upgraded the software on this blog to WordPress 2.7. The major new feature I am interested in is automatic upgrading, which could prove quite a time saver. Unfortunately, this automatic upgrading uses only FTP (which is totally insecure) or FTPS (which requires me to set up an SSL certificate).

I noticed that the WordPress code had ssh2 support built-in, so all I need to is activate SSH2 support in the MacPorts installed PHP and I should be able to use SFTP in WordPress to handle the upgrades. I poked around and found this posting outlining the process for adding ssh2 support to Ubuntu. It guided me in developing this list of hints:

1. Start by installing libssh2 via MacPorts using the command:
   

   sudo port install libssh2
   

2. Once it is activated, link the libssh and PHP together using the PECL module SSH2. Unfortunately, directly installing the module with PECL under MacPorts is troublesome, so I just used PECL to download the module.
   

   pecl download ssh2
   

   triggered the following error (since ssh2 is apparently beta),
   

   Failed to download pecl/ssh2 within preferred state "stable", latest release is version 0.11.0, stability "beta", use "channel://pecl.php.net/ssh2-0.11.0" to install
   Cannot initialize 'ssh2', invalid or missing package file
   Package "ssh2" is not valid
   download failed
   

   so I used
   

   pecl download channel://pecl.php.net/ssh2-0.11.0
   

   as suggested and was able to download the PHP library for SSH2. Once the download was complete, I started on the standard compilation sequence for a PHP library
   

   tar xzvf ssh2-0.11.0.tgz
   cd ssh2-0.11.0
   phpize
   ./configure --with-ssh2=/opt/local
   make
   sudo make install
   

   The final command informed me the ssh2.so library was placed in /opt/local/lib/php/extensions/no-debug-non-zts-20060613/
3. Now you need to make sure PHP loads the new module, so we open the PHP configuration file /opt/local/etc/php.ini and edit the extension_dir line to point the extension directory above:
   

   extension_dir = "/opt/local/lib/php/extensions/no-debug-non-zts-20060613/"
   

   and then add the following line to the end of the section on “Dynamic Extensions”:
   

   extension=ssh2.so
   

   If you edited everything properly, a simple php -v from the command line should NOT trigger any errors.
4. Finally, I restart the apache2 server so that the reconfigured PHP is loaded using
   

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

   At this point, I checked (via the phpinfo(); command to see if the web server was supporting SSH. Near the bottom of the phpinfo(); listing is a listed of “Registered PHP Streams”. As noted here, it should incude “ssh2.shell”, “ssh2.exec”, “ssh2.tunnel”, “ssh2.scp”, and “ssh2.sftp”. If it does, you have enabled SSH support for Apache2 driven PHP pages under MacPorts.
5. If you are doing this to get WordPress 2.7 automatic installation working, you will notice now when the automatic installation dialog box pops up, in addition to ftp and ftps, you now have an ssh option.
   

6. Now that I got this working, I’ll just have to keep an eye out for any future MacPort updates to PHP and make sure they don’t overwrite the

   /opt/local/etc/php.ini

   file or the extensions directory where I installed ssh2.

The solution suggested on the PHP boards is to compile PHP against expat. This would be kind of a pain for me since I am using the MacPorts install of PHP. So I looked into rolling back to an earlier version of libxml2 using MacPorts. The solution was originally outlined in this blog post by Stephen Chu on how to install earlier versions of ruby under DarwinPorts, I have updated it for MacPorts. The key is to create a local MacPorts repository with the version of the port you want copied over to it.

1. First I identified the version of the libxml2 portfile I wanted by going to http://trac.macports.org/browser/trunk/dports/textproc/libxml2/Portfile and entering revisions into the “View revision” box until I found the appropriate version of the Portfile linking to libxml2 2.6.32 instead of 2.7.1. This turned out to be revision 40211 (actually 39551).
2. I created a directory to contain my MacPorts repository at /Users/Shared/dports/ and after creating that directory, I edited the MacPorts configuration file /opt/local/etc/macports/sources.conf to include the line:

   file:///Users/Shared/dports

   and you should make this line appear before the “rsync” or svn” port listing in the config file, otherwise it defaults to using that version of the port during the install.

3. I then installed the old libxml2 port into my local MacPorts respository using subversion:

   svn co --revision 40211 http://trac.macports.org/browser/trunk/dports/textproc/libxml2/ textproc/libxml2/
   

   and then I updated the MacPorts index:

   portindex /Users/Shared/dports

   With this done, I can see the two versions of libxml2 in my ports list, when I issue a

   port list libxml2

   the result is:

   libxml2 @2.7.2 textproc/libxml2 libxml2 @2.6.32 textproc/libxml2

   showing the current libxml2 version in MacPorts and the older one in my repository.

4. Now I can install the older version of libxml2 by first forcing removal of the current version and then installing the old version:

   sudo port -f uninstall libxml2 @2.7.2_1+darwin_9 sudo port install libxml2 @2.6.32

   [Warning: Unless you place the file:///Users/Shared/dports line before any rsync/svn lines of the config file noted in step 2, this port install command installs the current version instead of the old version]

5. I had to forcible uninstall and then reinstall libxslt but then my reinstall of php within MacPorts went fine. And I can now use WordPress again without any issues when using a remote blog editor.

I just figured in case anyone else wanted to use an older MacPort port they could use this to figure out how.

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.

error when fonts are used in PHP routines (fuller notes on this problem here although with my “hacked” fix, which is no longer needed). This problem as originally reported under Trouble Ticket #15909 on MacPorts.

Careful with that Apache2 upgrade, Eugene: I also discovered I have to be careful when updating apache2 under MacPorts in that it actually wiped out some of the configuration files stored in /opt/local/apache2/conf/, specifically it overwrote my modified versions of the /opt/local/apache2/conf/extra/httpd-dav.conf file and /opt/local/apache2/conf/extra/http-userdir.conf files. So now I am keeping copies of everything in /opt/local/apache2/conf backed up so I can roll back my changes after an upgrade of apache2 in MacPorts.

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.

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.

Finally, there’s a big problem with FreeType. As I discovered, anytime FreeType fonts are used by GD, they apparently make a Carbon API call of some sort. Problem is, Apache2 uses fork() without a corresponding exec() and, upon calling PHP/GD/FreeType, the Carbon call in FreeType causes Apache2 to crash. It shows up in the error_log as

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.
Mon Nov 26 12:38:11 2007 notice child pid 304 exit signal Trace/BPT trap (5)

and in the system.log as

Nov 26 13:12:00 shr-g5 ReportCrash664: Formulating crash report for process httpd659
Nov 26 13:12:02 shr-g5 ReportCrash664: Saved crashreport to /Library/Logs/CrashReporter/httpd_2007-11-26-131145_shr-g5.crash using uid: 0 gid: 0, euid: 0 egid: 0

I didn’t discover the cause–I can’t take credit for this one.

[I]nstall FreeType 2 without the Mac-specific extensions. These extensions make it possible for FT2 to access fonts stored in a font suitcase, something which is unnecessary if you use plain “.ttf” fonts from other sources. Here’s how I did that: Get FT2 and expand the tarball: (in Sources–my version of /SourceCache):

curl -O http://download.savannah.gnu.org/releases/freetype/freetype-2.3.5.tar.gz
cd ..
tar xvfp Sources/freetype-2.3.5.tar.gz

Configure FT2 and make it:

MACOSX_DEPLOYMENT_TARGET=10.5 CFLAGS="-arch ppc -arch ppc64 -arch i386 -arch x86_64 -g -Os -pipe -no-cpp-precomp" CCFLAGS="-arch ppc -arch ppc64 -arch i386 -arch x86_64 -g -Os -pipe" CXXFLAGS="-arch ppc -arch ppc64 -arch i386 -arch x86_64 -g -Os -pipe" LDFLAGS="-arch ppc -arch ppc64 -arch i386 -arch x86_64 -bind_at_load" ./configure --with-fsspec=no --with-fsref=no --with-quickdraw-toolbox=no --with-quickdraw-carbon=no
make
sudo make install

Libraries end up in /usr/local/lib.

I had tried to alleviate the solution previously by compiling a version of PHP myself that would be compatible with Apple’s built-in Apache 2 web server. This turned out to be difficult because Apple’s Apache 2 web server is a “universal” binary, meaning it contains four seperate binaries (for 32-bit PowerPC, 64-bit PowerPC, 32-bit Intel, and 64-bit Intel processors). As such I needed to compile a “universal” PHP binary and since I wanted MySQL support, I needed a “universal” MySQL binary. This turned out to be too much for this astronomer, so I gave up on making a new PHP that was compatible with Apple’s built-in web server.

So I bit the bullet and after reviewing the options, I decided to install Apache 2 and PHP under MacPorts. If you have read the other posts on this site, you know I really like MacPorts as the quick and dirty way to get many things running on the Mac. However, despite this, I don’t like installing MacPorts for items Apple provides, instead generally preferring to use Apple’s “pre-installed” versions. Furthermore, there have been a lot of complaints on the MacPorts mailing lists about various issues compiling PHP5. So I wasn’t as quick to jump onto the MacPorts bandwagon for PHP as I am for other problems. However, since I am familiar with MacPorts, I decided this was the best approach for getting my online Finder Charts to work again.

The process proved reasonably painless, especially since I was able to review this blog post, where he lays out pretty much what to do. However, since I wanted to achieve maximum compatibility with Apple’s built-in web server and PHP setup, in case I wanted to switch back, I ended up doing things a little bit differently, so I am outlining my steps here.

1. I started by installing the MacPorts version of Apache 2 using the command sudo port install apache2
2. Next, I had to create the Apache 2 configuration files and edit them. I started by copying the sample configuration file

   sudo cp /opt/local/apache2/conf/httpd.conf.sample /opt/local/apache2/conf/httpd.conf

   and then editing /opt/local/apache2/conf/httpd.conf with my favorite text editor to change the configuration to match the that of the built-in Apache 2 server a closely as possible. My matching the configuration of Apple’s built-in server, I can switch back to it with relative ease if I choose to do so later. So I made the following changes to /opt/local/apache2/conf/httpd.conf:
3. 1. I changed DocumentRoot to "/Library/WebServer/Documents" as is the case with Apple’s built-in server.
   2. To allow index.php files to be used as directory indexes, I changed

      DirectoryIndex index.html

      to

      DirectoryIndex index.html index.php

      (I don’t know why this isn’t necessary with Apple’s built-in server, but it was necessary here).
   3. I changed to and in that directory block of code, I added “MultiViews” to the Options line.
   4. I changed to in order to prevent the listing of .DS_Store files in directory listings by the web server.
   5. Before the ErrorLog block of code in this file, I added the following lines copied from Apple’s default Apache 2 configuration:

      #
      # Apple specific filesystem protection.
      #
      
      Order allow,deny
      Deny from all
      Satisfy All
      
      Order allow,deny
      Deny from all
      Satisfy All

   6. I changed ErrorLog to "/private/var/log/apache2/error_log"
   7. I changed CustomLog to "/private/var/log/apache2/access_log common"
   8. To match Apple’s Apache 2 server configuration, I changed ScriptAliasMatch to

      ^/cgi-bin/((?!(?i:webobjects)).*$) "/Library/WebServer/CGI-Executables/$1"

   9. I changed back to
   10. I added the following Handles to the “To use CGI Scripts” block of code:

       AddHandler imap-file .map
       AddHandler cgi-script .cgi
       AddHandler cgi-script .pl

   11. I uncommended the following lines near the end of the file:

   12. [OPTIONAL] Because I use the WebDAV server on my server, I also uncommented
   13. Finally, I added the following lines to the end of the file in order to allow loading of the PHP5 configuration

4. Next, I editted /opt/local/apache2/conf/extra/httpd-userdir.conf and added the following to the end of the file

   #
   # Users might not be in /Users/*/Sites, so use user-specific config files.
   #
   Include /private/etc/apache2/users/*.conf

5. [OPTIONAL] Since I use the built-in WebDAV server, I made a backup of the WebDAV configuration, then copied the Default MacOS X one, because I have spent a lot of time tweaking it previously and I didn’t want to have to reinvent the wheel. 

   sudo cp /opt/local/apache2/conf/extra/httpd-dav.conf /opt/local/apache2/conf/extra/httpd-dav.conf.orig
   sudo cp /etc/apache2/extra/httpd-dav.conf /opt/local/apache2/conf/extra/httpd-dav.conf

6. I had to install PHP5 with MacPorts. Since I wanted to add support for Apache 2 and MySQL, I entered the command: sudo port install php5 +apache2 +mysql5 +pear which has the side effect of installing MacPorts version of MySQL as well. Assuming everything goes well, after a few minutes (this takes longer than the apache2 install earlier), the installation will end. At this point we can configure the Apache 2 mod_php module by typing: 

   cd /opt/local/apache2/modules/opt/local/apache2/bin/apxs -a -e -n "php5" libphp5.so

7. [OPTIONAL] Next, I had to create the PHP5 configuration file and edit it. I started by copying the sample configuration file sudo cp /opt/local/etc/php.ini-dist /opt/local/etc/php.ini and then editing /opt/local/etc/php.ini to make it match /etc/php.ini (which Apple’s built-in PHP uses). All the changes I made were optional and related to the specifics of my setup. The only interesting one was that I wanted to continue to use the MySQL.com binary distribution of MySQL server, so I set the following variables in /opt/local/etc/php.ini: 
   1. mysql.default_port from “” to 3306
   2. mysql.default_socket from “” to /private/tmp/mysql.sock
   3. mysqli.default_socket from “” to /private/tmp/mysql.sock
8. I deactivated Apple’s built-in web server by turning off Web Sharing in the Sharing.prefPane.
9. Finally, I launched the new webserver (and set it up for launching on boot-up in the future) by typing

   sudo launchctl load -w /Library/LaunchDaemons/org.macports.apache2.plist

   If this breaks anything, I can reverse the process by typing

   sudo launchctl unload -w /Library/LaunchDaemons/org.macports.apache2.plist

10. [OPTIONAL] I like the ability to turn on and off the Apache webserver from the command line using apachectl. I can “emulate” this in /bin/tcsh (my prefered shell) by adding the following command to the ~/.tcshrc file:

    alias apache2ctl 'sudo /opt/local/etc/LaunchDaemons/org.macports.apache2/apache2.wrapper'

    After which I can bring down the server by typing apache2ctl stop and restart it by typing apache2ctl start.

• Upgraded the freetype library to version 2.3.6, which fixes “A bunch of potential security problems have been found [and fixed in this release”
• Upgraded to pixman library to version 0.11.4.
• Xquartz fixes from xorg-server-1.3.0-apple21, the key fix being support for monitor hotplugging, although several security fixes also occurred.

Again, if you upgrade MacOS (say to version 10.5.4, which is supposed to be released soon in order to support iPhone G3 and MobileMe), you will likely need to reinstall Xquartz (unless Apple has upgraded their X11 installation to match Xquartz).

sudo port -d selfupdate
sudo port -d sync
sudo port install osxutils 

• Check Hardware Compatibility: My Sonnet Tempo SATA X4P card (which I use to provide an external SATA [eSATA] interface for my RAID of data drives) was incompatible with Leopard and would cause the installer to hang. I finally discovered a firmware upgrade was available that fixed this. This was a stupid rookie mistake. Rule of Thumb: Always check the non-Apple hardware for updates before making a major OS X upgrade.
• Watch out for /home: I had been using a symbolic link from /home to /Users because in my old Unix days, I hardcoded a lot of my software to look for my home directory in /home. Leopard expects /home to be available as mount point for the automount service, so getting with the modern era and not relying on /home to point to /User is required if you adopt Leopard.
• Rebuild Web Server Configuration: One problem I was prepared for is that the web server was updated to Apache2. This in itself was not bad, but the configuration files for Apache (version 1) were stored in /etc/httpd and the new configuration files for Apache2 are in /etc/apache2 and they were NOT migrated. I don’t fault Apple for not migrating the files, but I kicked this around on my laptop quite a bit in order to tweak the configuration files back to something I liked. One thing I immediately did was that this MacOS comes with PHP 5.2.4 preinstalled, but not enabled in Apache2. I enabled it by editting the /etc/apache2/httpd.conf file (which you might have to create) and uncommenting the line with # LoadModule php5_module (by removing the ‘#’ symbol from the beginning of the line). Once that was done, I restarted the Apache2 server and all my PHP code (including this blog) was running again.
• Tweak MySQL for Leopard: The PHP 5.2.4 included with MacOS X is compiled with support for MySQL. This is nice in that you can just download the MySQL package installer and quickly get a LAMP server running. However, it was set up with the MacOS X Server version of MySQL in mind, which means it expects the socket to be in a different location than the vanilla MySQL. This can be solved by either tweaking the MySQL configuration (as outlined in the MySQL section of the blog post at http://remysharp.com/2007/10/27/lamp-in-leopard-osx-105-php5-and-apache-22/ ) or by tweaking the PHP configuration by editing the /etc/php.ini file (if it doesn’t exist, first copy /etc/php.ini.default to /etc/php.ini) and search for the line containing mysqli.default_socket = to read
  

  mysqli.default_socket = /private/tmp/mysql.sock
  

  This solution seemed more straight forward, so I did this.
• Reinstall MacPorts: Since I am aficionado of MacPorts, I reinstalled it and rebuilt all the ports. Some of the issues I had before with MacPorts on Leopard on my MacBook Pro cropped up again on my PowerMac G5, notably
• • gv still needs to be patched as I noted here.
  • sqlite3 still does know about its dependence on nawk.
  • xterm doesn’t install unless you update your X11 installation using the latest version of Xquartz (currently at version 2.1.4).
• Update to latest version of Xquartz: Since I don’t like X11 headaches, I updated to the latest version of Xquartz (currently at version 2.1.4).

So the adventure continues. Back to research, I have invested about 5 hours of my spring break into this upgrade, that is enough for now.

The build.args need to be set as described in the INSTALL file.

So I updated the ports files via an

sudo port -d sync

sudo port install xephem

sudo rm -rf /usr/local/bin/xephem /usr/local/xephem /usr/local/man/man1/xephem.1

sudo port install aquaterm chmdump contacts coreutils curl file findutils g95 ghostscript gv ImageMagick ksh93 latex2rtf lynx macutil osxutils plotutils subversion teTeX tidy vim wget wine xterm xephem

• xterm, wine, and g95 all now install without any issues.
• teTeX can be installed, there was a bad dependency in the portfile. You just needed to install openmotif first manually. I don’t know if the bad dependency is still there, it may have been resolved.
• subversion can be installed, it also had a bad dependency. You just needed to install nawk first. Again, I don’t know if the bad dependency is still there, it may have been resolved.
• gv can be installed if you apply a patch. If you check that bug ticket on gv (you need to get a free MacOSForge account), you will find a new patch-setenv.c file is available there. If you download that file and replace /opt/local/var/macports/sources/rsync.macports.org/release/ports/print/gv/files/patch-setenv.c with it, gv will compile and install just fine.

This leaves just two of my standard suite of packages that don’t compile right in Leopard, osxutils (See this post) and xephem (See this post). And xephem installs just fine manually if you download the source code.

• I discovered that teTeX failed to build. This appears to be due to an undeclared dependancy on openmotif. So after the failed install, I just did ansudo port clean --work teTeX; sudo port install openmotif teTeXand teTeX installed just fine.
• In attempting to build subversion I discovered that one of the packages subversion needs, sqlite3, fails to install on Leopard. This appears to be due to an undeclared dependancy on nawk (MacPorts Report Ticket #13500). So again, all I had to do was:sudo port clean --work sqlite3; sudo port install nawk subversionand it worked. I should note that a fairly recent version of subversion now comes with Leopard, version 1.4.4 (as opposed to 1.4.5 with MacPorts).
• gv fails to install unless you patch it. This was reported to MacPorts (Bug Report Ticket #13095). [If you check that bug ticket, you will find a new patch-setenv.c file is available there. If you download that file and replace /opt/local/var/macports/sources/rsync.macports.org/release/ports/print/gv/files/patch-setenv.c with it, gv will compile and install just fine.]
• osxutils fails almost immediately with a series of errors about conflicting types. Since osxutils did a lot of meta-data manipulation, I am not completely surprised it is broken under Leopard. I have submitted a bug report to MacPorts.
• xterm fails to build. This is irritating because I haven’t had time to confirm is the old xterm Tektronix emulation bug present in the Tiger version of xterm is still present. [This appears to have been cleared up with MacPorts 1.6 if you install Xquartz over the Apple installed X11 server. Doing this is a good idea anyway.]
• wine fails to build (already reported elsewhere). This has already been reported in MacPorts Bug Report Ticket #13488. I wonder if this is related to the possibility being mentioned of Leopard having unreported support for Windows binary execution. [Wine version 0.9.51 DOES compile under Leopard just fine.]
• I can’t build g95 because odcctools fails to compile. This has been reported in MacPorts Bug Report Ticket #13148. [This appears to have been fixed as of January 24, 2008.]
• xephem fails to build because lesstif builds but fails to install. Actually lesstif installed fine once I moved /usr/share/aclocal/ac_find_motif.m4 out of the way. I don’t know if that file was there from my previous install of lesstif. Once lesstif was out of the way, xephem failed to build. Interestingly, MacPorts has version 3.7, I downloaded the source for xephem 3.7.2 from the Clear Sky Institute website, compiled it following the installation instructions without a hitch. I submitted a bug report as MacPorts Bug Report Ticket #13524 (turned out my bug report was a duplicate of MacPorts Bug Report Ticket #13498). This has been fixed, see this post. [This appears to have been fixed as of March 3, 2008.]

• I uninstalled Unsanity’s Application Enhancer.
• I removed X11.app from my automatic launch items in the Accounts Preferences Pane Login Items. X11 is extensively refreshed under MacOS 10.5, so you don’t want to autolaunch X11.app any more.
• I upgraded Cisco’s VPN software to the latest version distributed by my campus (you want Cisco VPN Client 4.9.01 (0090)).
• I did a quick search of the various applications I run and looked for “Leopard” upgrades via MacUpdate.
• Finally, I researched the incompatibility of Adobe Acrobat with MacOS X 10.5. I discovered that while the AdobePDF printer driver broken under the new OS, you can use Apple’s built in PDF capability (specifically “Save as PDF-X”) capability to create the PDF, which can then import and edit just fine in Acrobat.

Having done all that, I decided to bite the bullet and install the upgrade. First thing I did was back up the entire internal drive to an external drive (which I had formatted with Disk Utility to make sure it was capable of booting an Intel Mac) using Carbon Copy Cloner. Once the drive was cloned, I ignored the overhyped warnings from MacFixIt.com (who I won’t link to, because they were bought out, they definitely sold out as a source of accurate help) and instead followed the Apple recommended procedure of just doing an upgrade to my previous Tiger installation. I figured if worst came to worse, I would recover from the backup drive (in my mind, the backup is the critical step, not how you choose to upgrade). So approximately 80 minutes later my laptop finished its upgrade and rebooted. Some notes on my initial issues with the new OS.

• The new dock doesn’t bug me as much as some (John Siracusa does the best analysis of the problems with the new Dock in his extensive ArsTechnica review of Leopard), but maybe its because I thought the old dock was broken enough as a launcher that I use QuickSilver instead (which works fine under Leopard).
• Leopard finally handles virtual memory use nicely, removing old files in the /var/vm directory once the memory has been released.
• I don’t like the translucent menubar, but there exist various free applications to get rid of those and the changed dock.
• The new OS nuked all my installed printers. Not a huge deal, but I have to re-install all my printers again. I kind of understand why this might of happened, but it was a pain.
• I had to use Disk Utility to Repair Permissions before my Widgets behaved properly, but now, they actually seem to run better than before (less delay in accessing them).
• I patched IDL to version 6.4.1, seems to work now.
• I knew from Ben Bayer’s (Apple’s X11 guy) postings on the matter that
  

  Biggest architectural change in Leopard for X11: Switched from XFree86 codebase (based on, IIRC, X11R6.8) to X.org codebase (X11R7.2)

  Biggest user-visible change: launchd support for X11. The only situation where you should need to manually start X11.app is if you are only running remote X11 applications.

  The way that this is accomplished is by some slight-of-hand with the $DISPLAY variable — if you look, it should be something like “/tmp/ launch-vbXRyu/:0″. If an X client connects to this, it will actually connect to launchd, which will start Xquartz if needed and pass the client’s socket to the server.

  All of that should be invisible to you; the X client library (libX11.dylib) was modified to support this, and all X11 applications link against this library. “DISPLAY=:0″ would still work if X11.app is already running, but it will not trigger X11 to launch.

  So in other words, we are not supposed to set the shell environmental variable DISPLAY to “:0″. Well, I removed all the times I set it from .tcshrc, .bashrc, .login, etc and it still remained stubbornly set until I remembered trying to get Carbon Emacs working a few months back required my setting environmental variables to my entire session using the ~/.MacOSX/environment.plist file. I opened it, removed the DISPLAY variable from the list of those set for the entire session, and viola. Almost everything worked as advertised except:

• SAOImage DS9 refused to launch because of the non-standard DISPLAY variable. I initially hacked around this by launching an xgterm (from IRAF) and setting the DISPLAY variable in it to “:0″ then launching ds9 within that xgterm session. I did this all in one line via: 

  xgterm -geometry 80x45+40+30 -sb -e 'setenv DISPLAY :0; ds9 -fifo ~/iraf/dev/imt1 -geometry 800x800+600+30 &'

  where I was connecting to my IRAF pipes (thus the ‘fifo’ command line entry). However, I emailed the SAOImage DS9 folks on Thanksgiving and they replied same day to tell me about the new ds9 darwin 5.1beta. That fixed the launch issues with ds9. Apparently getting the Aqua version updated is a bit trickier, so its not done yet.
• I had to uninstall the MacPorts version of xephem, but installing it manually from the source worked just fine.
• I installed the unofficial updates to X11 from Xdarwin (see MacSingularity for some notes). The biggest issues this fixes are (1) the focusing problem of X11 windows behind Aqua windows not always being “focusable” and a (b) bug in X11 that caused several programs using the Gimp Toolkit (aka gtk) to crash. NOTE: These updates have been superceeded by those on the MacForce XQuartz updates site.

All in all, I like the new upgrade, the most useful feature for me being the QuickLook interface and the just generally better networking behavior. I also think there has been a lot of thought put into nips and tucks (such as where the Firewall controls are now, in the “security” prefpane instead of “sharing”). More reports from the field as my usage of IRAF and ds9 under Leopard continues.

[ChkTeX] has been written in frustration because some constructs in LaTeX are sometimes non-intuitive, and easy to forget. It is not a replacement for the built-in checker in LaTeX; however it catches some typographic errors LaTeX oversees. In other words, it is Lint for LaTeX.

Looks promising for me. I use Splint when C programming (I installed splint via MacPorts using the command line sudo port install splint), so the idea of a Lint for LaTeX is appealing. I’ll be visiting Dr. Figueroa-Centeno’s website on ChkTeX on Mac OS X for full details on installing it, once I get a break from teaching.

sudo port install xephem

XEphem.PrivateDir: ~/.xephem

XEphem.ShareDir: /opt/local/share/xephem/

I guess RTFM can actually be important!

I found that this problem had been reported on Apple’s X11-users mailing list here, but no solution had been determined. I spent a bit of time looking for “missing” fonts as suggested in the posting, then decided this had to be a problem with the xterm executable and tried my previous solution of installing the program from MacPorts via

sudo port install xterm

sudo mv /usr/X11R6/bin/xterm /usr/X11R6/bin/xterm.disabled
sudo ln -s /opt/local/bin/xterm /usr/X11R6/bin/xterm

#!/bin/ksh
ls -1 . | while read fname; do
  echo $fname
done

sudo port install ksh93

NOTE: I will assume you have installed teTeX (a modern LaTeX package) in one of a variety of ways. Personally I recommend either Fink or MacPorts. However you can get a lot more information about this by visiting the “Getting Started” page at the Mac TeX website.

AASTeX is used to help typeset publications for all the major astronomical journals (at least in the US). You have two fundamental options for installing AASTeX on the Mac:

1. Single User Install: The easiest way is to download AASTeX (the version for LaTeX 2e) from http://www.journals.uchicago.edu/AAS/AASTeX/ and then just copy the aastex.cls file to whatever directory contains your latex source code for your paper. It should work just fine if you do that.
2. Global Install: If you want to make the AASTeX class file available to all your Mac users, you need to install it globally where the laTeX installation keeps its latex libraries. The easiest way to do this is to first determine where teTeX keeps its laTeX libraries (referred to as TEXMFMAIN). One simple way to do this is to type the following from the command line
   

   texconfig conf | grep TEXMFMAIN

   
   Once you have found that directory, edit the Makefile that comes with AASTeX so that INSTALLDIR equals that directory and fire off a
   

   sudo make install

   
   Once you have installed AASTeX, run
   

   sudo texconfig rehash

   
   And you should be set.

P.S. – Most teTeX installs come set to European paper sizes. If you want US Letter size, just run the configuration program and set US Letter size pages as the default using:

sudo texconfig