Irritating Mongrel install problem

Here I am again, reporting about an issue that I've spent hours and hours trying to fix. This time I was doing a round of gem update --system and gem update to get my servers and laptop up to date. I had some problems on my Ubuntu servers, but those problems seem to have been known/common and/or just down to bad temper.
But one problem persisted. This on my laptop which is a MacBook which is about one year old and came with Mac OS X 10.4 Tiger and I upgraded it to Mac OS X 10.5 Leopard. The problem was that I could not get the gem install command to compile the gem native extensions for Mongrel. I kept getting this sort of error:
Computer:~ j$ sudo gem install mongrel
Bulk updating Gem source index for: http://gems.rubyforge.org/
Building native extensions. This could take a while...
ERROR: Error installing mongrel:
ERROR: Failed to build gem native extension.

/usr/local/bin/ruby extconf.rb install mongrel
checking for main() in -lc... no
creating Makefile

gcc -I. -I. -I/usr/local/lib/ruby/1.8/i686-darwin8.9.3 -I. -fno-common -g -O2 -pipe -fno-common -c http11.c
gcc -I. -I. -I/usr/local/lib/ruby/1.8/i686-darwin8.9.3 -I. -fno-common -g -O2 -pipe -fno-common -c http11_parser.c
cc -dynamic -bundle -undefined suppress -flat_namespace -L"/usr/local/lib" -o http11.bundle http11.o http11_parser.o -lpthread -ldl -lobjc
/usr/bin/ld: /usr/lib/gcc/i686-apple-darwin8/4.0.1/../../../libpthread.dylib unknown flags (type) of section 6 (__TEXT,__literal16) in load command 0
/usr/bin/ld: /usr/lib/gcc/i686-apple-darwin8/4.0.1/../../../libdl.dylib unknown flags (type) of section 6 (__TEXT,__literal16) in load command 0
/usr/bin/ld: /usr/lib/gcc/i686-apple-darwin8/4.0.1/../../../libobjc.dylib load command 9 unknown cmd field
/usr/bin/ld: /usr/lib/gcc/i686-apple-darwin8/4.0.1/../../../libSystem.dylib unknown flags (type) of section 6 (__TEXT,__literal16) in load command 0
collect2: ld returned 1 exit status
make: *** [http11.bundle] Error 1

Gem files will remain installed in /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.1.5 for inspection.
Results logged to /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.1.5/ext/http11/gem_make.out

I was totally puzzled and started googling my way through the problem. First I came across this problem with install vs. ginstall. I thought I was onto a winner. But, a) I don't have an /opt//usr/local/lib/ruby/gems/1.8/gems/mongrel-1.1.5 directory, and b) after loads of poking around in especially looking at the Makefile etc, I found that it was indeed reporting the install correctly (INSTALL = /usr/bin/install -c).
I then thought it was about the http11 and friends, well I knew it was compiling, but I thought something else about it was wrong.
By now I was hours into this. I had to figure out some other reason for this failing, so my attention swerved onto that it seemed to be /usr/bin/ld that was the problem. Having read half of this page, I realised that I probably needed the Mac OS developer tools, called XCode 3.0 for Leopard. Remember earlier when I said that the machine came with Tiger. Back then I installed XCode for Tiger, but I never got around to upgrading it (or maybe I thought it would have been upgraded autoMaccically). Said and done, I fetched the install DVD and popped it in. A good while later XCode 3.0 was installed and I tried the Mongrel install again:
Computer:~ j$ sudo gem install mongrel
Bulk updating Gem source index for: http://gems.rubyforge.org/
Building native extensions. This could take a while...
Successfully installed mongrel-1.1.5
1 gem installed
Installing ri documentation for mongrel-1.1.5...
Installing RDoc documentation for mongrel-1.1.5...
Computer:~ j$

Done! There it was! XCode was at an old version. So if you get some weirdness when installing/compiling on Mac OS X, make sure you've got the latest XCode installed.


Tooony said...

Yes, it is rather obvious from the errors you got that you were missing some shared library functionality, or that the make code were pointing to a hard linked .so file, which is more unlikely... . ;-)
Check your LD_LIBRARY_PATH env variable. I assume it is the same on Mac as on Linux ans Sun? Or is it like HP-UX named SHLIB_PATH, or like AIX named LIBPATH?

No, more seriously, from a public package like this I would have expected a bit better version control for what shared libraries to use and if they actually exists. It's not that hard to check for dependencies... Lazy bugger developers. ;-)

J said...

Thing is, Tooony, I'm no hard-core-geek, so those messages from GCC don't mean much to me. I'm therefore left to figure things out one by one, by using the almighty Google.
And what comes to version control, I don't know if there's actually been a version number change between Tiger and Leopard, maybe just some internal reshuffling. And I guess it would be difficult for an external developer to be able to identify these sort of things on all OSs'. I guess the real culprit here is Apple's version of GCC that should not have been running except under an environment that it considers safe.
Regardless of the true clutprit, I think it could have been fixed by Apple simply by checking the XCode version that was installed when I installed Leopard and offered a "serious" message that it should be upgraded.
Either way, one lives and learns. ;)

Tooony said...

Well, we do agree then. :o)
The developers creating the scripts for compiling and linking should have implemeted some basic checks for dependencies.
It might be difficult to create a multi platform check for that, but it is not impossible. :-) If they develop multi platform applications, they should really have that skills...

Not saying it is common for application developers to do so, but they really should. :-P