Not having dealt with any of the programs you mention, my guess is an architecture mismatch. :)
Although I haven't dealt with Passenger, I have dealt a lot with Apache on Leopard. I had similar problems with mod_python. As you know, Apache in 10.5 runs as a 64-bit app on architectures that support it. This requires that all of the binaries it links to to be 64-bit, which requires the binaries those binaries link to to be 64-bit, etc. Of course, some of those same binaries need to be used by 32-bit binaries. Unfortunately, although Apple has an elegant solution with fat binaries, it isn't used any where else and so it isn't incorporated into a lot of open source build systems. This causes problems.
Python on Leopard is a frustrating example. All of the binaries for Python are 64-bit fat, except one: python. That's right, the Python intepreter, /usr/bin/python, is 32-bit only. So every script you run and module you import has to be 32-bit. I believe they had to do this for compatibility reasons. Whatever, just compile all your modules 32-bit, who cares? Web developers. Because Apache runs 64-bit, mod_python runs 64-bit, and everything they link to has to run 64-bit. So now those 32-bit extensions are producing crashes just like what you are encountering. Sometimes it's as simple as setting CFLAGS and recompiling, but sometimes it is a real pain in the ass. For example, you can't compile PostgreSQL as a 32/64-bit binary. The build breaks.
Enter lipo. Lipo is made for creating and manipulating fat binaries. So in the case of PostgreSQL, what you have to do is compile to different versions of it, one 32-bit and one 64-bit, and then use lipo to combine the two versions into one fat binary.
So, what you want to do is take every binary that mod_rails will link to and run 'lipo -info' on it ('file' also works) and ensure that they all have x86_64 binaries in them. If not, you've found your problem. Either recompile or download the a 64-bit binary and use lipo. Sounds like MySQL is the place to start.
BTW, /usr/bin/ruby is 32-bit. And iPhones were not made for writing long comments.
by Nathan — Nov 06
Although I haven't dealt with Passenger, I have dealt a lot with Apache on Leopard. I had similar problems with mod_python. As you know, Apache in 10.5 runs as a 64-bit app on architectures that support it. This requires that all of the binaries it links to to be 64-bit, which requires the binaries those binaries link to to be 64-bit, etc. Of course, some of those same binaries need to be used by 32-bit binaries. Unfortunately, although Apple has an elegant solution with fat binaries, it isn't used any where else and so it isn't incorporated into a lot of open source build systems. This causes problems.
Python on Leopard is a frustrating example. All of the binaries for Python are 64-bit fat, except one: python. That's right, the Python intepreter, /usr/bin/python, is 32-bit only. So every script you run and module you import has to be 32-bit. I believe they had to do this for compatibility reasons. Whatever, just compile all your modules 32-bit, who cares? Web developers. Because Apache runs 64-bit, mod_python runs 64-bit, and everything they link to has to run 64-bit. So now those 32-bit extensions are producing crashes just like what you are encountering. Sometimes it's as simple as setting CFLAGS and recompiling, but sometimes it is a real pain in the ass. For example, you can't compile PostgreSQL as a 32/64-bit binary. The build breaks.
Enter lipo. Lipo is made for creating and manipulating fat binaries. So in the case of PostgreSQL, what you have to do is compile to different versions of it, one 32-bit and one 64-bit, and then use lipo to combine the two versions into one fat binary.
So, what you want to do is take every binary that mod_rails will link to and run 'lipo -info' on it ('file' also works) and ensure that they all have x86_64 binaries in them. If not, you've found your problem. Either recompile or download the a 64-bit binary and use lipo. Sounds like MySQL is the place to start.
BTW, /usr/bin/ruby is 32-bit. And iPhones were not made for writing long comments.