2008-05-28

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

make
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
Password:
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.

3 comments:

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