Oh, there is such joy in the process of upgrading to Mac OS/X Snow Leopard for us developer folks. Me, I chose the in-place ugrade path … my co-worker, who chose the from-scratch path, was deprived of some of these pleasures. Then again, he had to reconstruct everything from scrach, so he had his own barrel of monkeys to contend with.
Here’s all the bumps I ran into (pretty much in reverse order) as I tried (unsuccessfully) to do the minimum amount of work possible (oh, the irony). Of course you may run into a mess of fun issues not even described here … And pardon me if the instructions aren’t perfect, because I’ve tried to boil a lot of this down to the it-finally-worked steps extracted from the frenzied back-and-forth of my real-time upgrade experience
Yes, this is just common-sense developer stuff (as is a number of the other obvious things that I call out in this post).
You’ll probably want to do a full
mysqldump before upgrading. You can dump your
port install and
gem list --local listings up front as well, or wait ‘til you get to those respective steps below.
If you also chose the
MacPorts library system, you’ll need to re-install it from scratch. You’ll need
X11 from the Snow Leopard from the OS/X install disks, and download the latest version of Xcode. Follow the migration steps as outlined on their Wiki; it does the trick.
Save off your
port install list as a reference. Now, your MacPorts install will be completely toast, so that command won’t work until you re-install. No problem though – all of your packages will still be listed even after you upgrade.
port clean step in the Wiki will crap out in the
http* range, but that’s fine … you can probably skip that step anyway. Re-install your core packages and you’re good to go. I suggest installing
readline if you haven’t, because it’s very useful in
irb or any Ruby console.
It was not necesary for me to build MySQL from source. Instead, I just installed the x86_64 version of MySQL – the latest was
mysql-5.1.42-osx10.6-x86_64.dmg af the time of this writing.
If this is a 5.x verison upgrade for you as well, the install will just re-symlink
/usr/local/mysql, so your old data will still be in your previous install dir.
I didn’t make
mysqldumps before I did the upgrade (facepalm) so I had to copy over my
data/ files raw and hope that the new version would make friends with them. Initially I had problems with InnoDB. It wasn’t showing up under
show engines;, and when I tried to manually install the plug-in – per this bug report, which explains the whole thing – it would fail on the ‘Plugin initialization function’. Turns out you need to do two things when you bring over raw data:
- Whack your
/var/log/mysql/*binary*/ binary log files in order to get past
- Whack your
ib_logfile*files too. Once you do that, there’s a good chance MySQL will regen them in recovery mode. Me, I had no choice (except rolling back with Time Machine). Miracle of miracles … it works!
Don’t try this at home kids. Make your backups. Note: here’s the correct link to the manual page on InnoDB tablespace fun.
Snow Leopard is a lot more native 64-bit than previous OS/X versions, and when you do your manual builds & makes, you may want to set the following environment variable:
export ARCHFLAGS="-Os -arch x86_64 -fno-common"
You’ll see a set of similar (though mixed) recommendations in the blogs I reference below; this particular flagset worked for me.
I built Ruby 1.9 at work, and 1.8.7 on my personal machine. Either path is fine, just pick up the latest source of your choosing. Chris Cruft’s blog post goes into some of the details I’m describing here as well. Basically, the README boils down to:
% autoconf % ./configure --with-readline-dir=/usr/local % make clean && make % make install
Though there’s no reason in the world that you’d want to – it has been superceded – do not install ruby 1.9.1p243. If you do, you’ll never get the
mysql gem to work. Or wait, or was it
mongrel? Well, it was one or the other … just trust me, it’s bad.
I re-built gem from source from scratch as well, just to be sure. Save off your
gem env and
gem list --local as a reference. And before you start installing gems, you’ll also probably want to make sure you’re fully up-to-date with
gem update --system, though that’s probably redundant.
Uninstall and re-install all of your gems; if some won’t uninstall even though they’re listed, it may be an install path issue. Use
gem list -d GEMNAME to find where your gem was installed, and then use
gem uninstall -i DIRNAME GEMNAME to finish the job.
With the ARCHFLAGS in place, the vast majority of the native source gem builds will go smoothly, but there are some notable exceptions …
The mysql Gem
Uh huh, this is the one gem that gets me every time. And again, you won’t have needed to have built MySQL from source.
For starters, you may way want to glance over this very useful iCoreTech blog post to see if it works for you. But if you run into a lot of issues like I did, you may need to do it in two steps:
Fetch and Install the Gem
At the time of this writing, either
mysql gem version
2.8.1 will do the trick.
% gem fetch mysql --version VERSION % gem install mysql -- --with-mysql-dir=/usr/local --with-mysql-config=/usr/local/mysql/bin/mysql_config % gem unpack mysql
Sadly, it may fail, either during the build or when you try to test it. I was able to successfuly run the (included?)
test.rb at my workplace, but as simple as that sounds, I swear I don’t remember how I did it ! The second time, at home, I only found the problems retroactively when I tried to get my Rails projects to boot. If you do find and run the
test.rb, you’ll need to make sure that the standard MySQL
test database exists.
Both times, one of the big blockers that I – and many other people – ran into was:
NameError: uninitialized constant MysqlCompat::MysqlRes
If so, try this:
Manually Re-build the Binary
ext/mysql_api, make sure your
ARCHFLAGS are exported as described above, and …
% ruby extconf.rb --with-mysql-config=/usr/local/mysql/bin/mysql_config % make clean && make % make install
Hopefully your newly built & installed binaries will resolve the issue.
It took me a little effort to build mongrel on Ruby 1.9 with the x86_64 architecture. My memory is a little hazy – since my 1.8.7 build at home worked perfectly through standard
gem install – but buried deep in this Is It Ruby contributory blog post are probably all the answers you’ll need.
Under Ruby 1.9, I did had to modify the source, which (to paraphrase) involved some global code replacements:
- change the one-line
case ... whenstatements from Java-esque
And then the re-build:
% ruby extconf.rb install mongrel % make % make install % cd ../.. % ruby setup.rb % gem build mongrel.gemspec % gem install mongrel.gem
That’s as far as I had to go. Whew! I certainly hope that my post has been of some assistance to you (and with a minimum of unintended mis-direction). Of course, I learned everything the I reiterated above by searching the ‘net and plugging away. And there’s plenty of other folks who’ve gone down this insane path as well.
Good luck, brave soul!