B0rked ports on Snow Leopard

If you are using MacPort to manage OSS on your box and you recently upgraded to Snow Leopard you will find error messages like this when trying to use the ports system:

$ port selfupdate
dlopen(/Library/Tcl/macports1.0/MacPorts.dylib, 10): no suitable image
found.  Did find:
/Library/Tcl/macports1.0/MacPorts.dylib: mach-o, but wrong architecture
while executing
"load /Library/Tcl/macports1.0/MacPorts.dylib"
("package ifneeded macports 1.0" script)
invoked from within
"package require macports"
(file "/opt/local/bin/port" line 39)

The issue is simply that you have all your libs and binaries managed via MacPorts compiled for the i386 architecture and not x86-64 (as required for Snow Leopard).

The solution is simple, but, arduous. You need to install the new version of MacPorts for Snow Leopard, make a backup list of the installed ports, delete them and reinstall the ones you still want.

You may want to pay close attention to the variants of the ports that you had previously installed when reinstalling them.

Also, you need the latest version of Xcode (a version greater than v3.0 will do) installed.

Fun.

See the following two URLs for more info:

• Installing MacPorts
• Migrating a MacPorts install to a new major OS version or CPU architecture

Happy recompiling!

Installing ghc on OS X and getting "./configure: line 11082: syntax error: unexpected end of file"

While trying to install ghc from MacPorts I kept getting this:

[...]
--->  Fetching ghc
--->  Attempting to fetch ghc-6.10.3-src.tar.bz2 from 

http://distfiles.macports.org/ghc
--->  Attempting to fetch ghc-6.10.3-src-extralibs.tar.bz2 from 

http://distfiles.macports.org/ghc
--->  Attempting to fetch testsuite-6.10.3.tar.bz2 from 

http://distfiles.macports.org/ghc
--->  Attempting to fetch ghc-6.8.2-darwin-i386-leopard-bootstrap.tar.bz2 from 

http://distfiles.macports.org/ghc
--->  Verifying checksum(s) for ghc
--->  Extracting ghc
--->  Applying patches to ghc
--->  Configuring ghc
Error: Target org.macports.configure returned: configure failure: shell command 

" cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.

macports.org_release_ports_lang_ghc/work/ghc-6.10.3" && ./configure 

--prefix=/opt/local 

--prefix=/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.

macports.org_release_ports_lang_ghc/work/destroot/opt/local 

--datadir=/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.

macports.org_release_ports_lang_ghc/work/destroot/opt/local/share/ghc-6.10.3 

--with-gmp-includes=/opt/local/include --with-gmp-libraries=/opt/local/lib 

--with-ghc='/opt/local/var/macports/build/

_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ghc/

work/ghc-bootstrap/bin/ghc' --with-gcc=/usr/bin/gcc-4.0 " returned error 2

Command output: checking build system type... i386-apple-darwin9.7.0
checking host system type... i386-apple-darwin9.7.0
checking target system type... i386-apple-darwin9.7.0
Canonicalised to: i386-apple-darwin
checking version of ghc... 6.8.2
checking for nhc... no
checking for nhc98... no
checking for hbc... no
checking for ld... /usr/bin/ld
./configure: line 11082: syntax error: unexpected end of file

Turns out there's some old cruft in the ghc autoconf macros that were causing the break. The fix was a simple:

$ sudo port selfupdate && sudo port clean ghc && sudo port install ghc

You can see the filed bug and changeset at MacPorts for more information.

Aspell, PSPELL, PHP and OS X

Until quite recently there was no way to use Aspell (via the PSPELL PHP libs) on an OS X host that was using the MacPorts system for package management.

This was simply because of the lack of a pspell variant for the php{45} packages.

Port of call
The ports system has the notion of a variant for packages that are conditional modifications of port installation behaviour.

There are two types of variants: user-selected variants and platform variants.

User-selected variants are options selected by a user when a port is installed while platform variants are selected automatically by MacPorts' base according to the OS or hardware platform (Darwin, FreeBSD, Linux, i386, PPC, etc.).

More stuff and less fluff
There are several ways of working this. The first would be to log a ticket at the MacPorts trac with a request to add the variant.

Depending on the package maintainer's load you may be a response pretty quickly. I've generally gotten something back within days of logging the ticket.

In the meantime your universe cannot come to a halt waiting for someone else to add the next greatest thing as a variant to your favourite package. So here's some manual steps to get things up and running in the meantime:

• Install Aspell
  
• Recompile and install PHP with the required PSPELL support
  
• Check php to ensure the new PSPELL libs are active
  
• Do a simple test to see if everything is working as it should
  

Install Aspell
I'll assume you're using MacPorts for your your package management on your OS X host.

Grab the aspell application, libs and whichever dictionaries catch your fancy:

$ sudo port install aspell aspell-dict-en


Be sure to install at least one dictionary or your spell checking days will be rather deflated.

Recompile and install PHP with the required PSPELL support
To manually add a compilation flag you need to edit the Portfile that comes with your installed PHP version. Mine is located at:

/opt/local/var/macports/sources/rsync.macports.org/release/ports/www/php5/Portfile

Edit the Portfile and add “–with-pspell=${prefix}” to configure.args. You can then re-ininstall PHP and it should now use the modified Portfile to compile PHP.

Check php to ensure the new PSPELL libs are active
Use the following script from the command line to determine if your PHP was re-installed with the required PSPELL bits enabled:

$ php -r 'phpinfo();' | grep PSpell
PSpell Support => enabled

Do a simple test to see if everything is working as it should
You should be able to just use the example from the PHP documentation page to ensure everything is fine:

$ cat /tmp/t_pspell.php

$ php -f /tmp/t_pspell.php
Sorry, wrong spelling

The packaging gods exist!
A few days after creating this ticket on the MacPorts trac I got a response from the package maintainer informing me that the variant had been added to all the relevant PHP packages.

Cool!

If your ports distribution files are up-to-date you should now be able to do the following to see which variants are available for your PHP version of choice:

$ port info php5
php5 5.2.5, Revision 2, www/php5 (Variants: universal, darwin_6, darwin_7, macosx, apache, apache2, fastcgi, gmp, imap, pspell, tidy, mssql, snmp, macports_snmp, mysql3, mysql4, mysql5, oracle, postgresql, sqlite, ipc, pcntl, pear, readline, sockets)
http://www.php.net/

PHP is a widely-used general-purpose scripting language that is especially suited for developing web sites, but can also be used for command-line scripting.

Library Dependencies: libxml2, libxslt, openssl, zlib, bzip2, libiconv, expat, gettext, tiff, mhash, libmcrypt, curl, pcre, jpeg, libpng, freetype
Platforms: darwin freebsd
Maintainers: ryandesign@macports.org jwa@macports.org

Now that pspell is listed as a variant you can install PHP with this variant by doing the following, after removing previous PHP version:

$ sudo port install php5 +pspell


Unholy Triumvirate: TextMate, MacPorts and Ruby

After switching back from a Ubuntu laptop to my MacBook Pro I was once again getting back to using TextMate to do some development and systems scripting. The combination of ruby and RubyGems have been a little bit rocky on OS X.

In part it was due to the default install of ruby on OS X, me using Fink for package management and then later switching from that to MacPorts.

Apple (and I presumably) suck cvyrf.

The problem I ran into was that after installing ruby and rb-rubygem via the ports system, TextMate no longer seems too interested in compiling ruby scripts when I hit CMD-R and provides me with a lovely:

"No such file to load ” rubygems

Checking Google the first listing I get is this.

It did not provide me with an applicable solution but got me thinking ... Either I have some environment variables that are not being set (or set incorrectly) or my library paths are screwy somehow.

An easy way to confirm the former is to check if your shell environment also suffers from the same malady:

$ ruby -r rubygems -e "p 1"
1

Not the problem then. Next step, let's pull out find and off a hunting we go:

$ sudo find / -name ruby -type f
Password:
/opt/local/bin/ruby /opt/local/var/db/dports/software/ruby/1.8.6_0/opt/local/bin/ruby /usr/bin/ruby

Let's see if there is some disparity between the ruby binary in /opt/local/bin and /usr/bin:

$ /usr/bin/ruby -v
ruby 1.8.2 (2004-12-25) [universal-darwin8.0]
$ /opt/local/bin/ruby -v
ruby 1.8.6 (2007-03-13 patchlevel 0) [i686-darwin8.9.1]

Well, what do you know. The version in /usr/bin is older and also looks for its libs in a non /opt location which means that it won't pick up the good work port has done for me. I moved /usr/bin/ruby to /tmp and added a soft link for /opt/local/bin/ruby to /usr/bin.

Running my script in TextMate now works like a charm!