I use FogBugz as my main bug tracking and customer support system. It's a neat application that runs on PHP and a web interface and allows me to both keep track of bugs/features in my development, as well as handle all tech support e-mail. It's designed with a multi-user environment in mind, but works quite well for a one-man shop such as myself. The web interface is not as good as a true desktop interface could be, but it's perfectly sufficient, and I've become quite dependent on FogBugz as part of my daily workflow.Dependent enough that it was a rather rude (but not wholly unexpected) discovery to find that upgrading to Leopard pretty soundly hosed my FogBugz installation. Not that it went and deleted files or data or anything, but the setup was quite far from working normally.The primary cause for this was that Leopard now ships with Apache 2.2, whereas Tiger came with Apache 1.3. All the various differences are well documented out there on the intertubes, but a lot of things, such as where configuration files are stored, changed between the two versions. For example, instead of httpd.conf being in /etc/httpd, it now resides in /etc/apache2.I got that part figured out pretty quickly, but then when I went to start up the web server, I would get a message printed in the system console reading:Oct 30 12:07:57 bw-mbp org.apache.httpd: httpd: Syntax error on line 484 of /private/etc/apache2/httpd.conf: Syntax error on line 8 of /private/etc/apache2/other/+entropy-php.conf: Cannot load /usr/local/php5/libphp5.so into server: dlopen(/usr/local/php5/libphp5.so, 10): no suitable image found. Did find:nt/usr/local/php5/libphp5.so: no matching architecture in universal wrapperHmmm, well, I do have a custom build of PHP5 (in /usr/local/php5, with additional extensions needed for FogBugz) and it seems to be finding that OK, but it's complaining about architecture something-or-other. I'm still running on Intel, aren't I?[bw-mbp:~] bwebster% file /usr/local/php5/libphp5.so/usr/local/php5/libphp5.so: Mach-O universal binary with 2 architectures/usr/local/php5/libphp5.so (for architecture ppc): Mach-O bundle ppc/usr/local/php5/libphp5.so (for architecture i386): Mach-O bundle i386Yeah, that's got an Intel build in there, that's OK. What the heck is Apache's problem?[bw-mbp:~] bwebster% file /usr/sbin/httpd/usr/sbin/httpd: Mach-O universal binary with 4 architectures/usr/sbin/httpd (for architecture ppc7400): Mach-O executable ppc/usr/sbin/httpd (for architecture ppc64): Mach-O 64-bit executable ppc64/usr/sbin/httpd (for architecture i386): Mach-O executable i386/usr/sbin/httpd (for architecture x86_64): Mach-O 64-bit executable x86_64Oooh, I see 64-bit stuff in there, don't I? I suppose that could be a problem if it's trying to load a 32-bit library. Well, the packaged PHP that I installed from entropy.ch hasn't been updated yet for Leopard, so I guess I'll have to download and compile PHP myself so I can get in on the 64-bit goodness.*insert footage of Brian downloading a bunch of stuff, typing ./configure and make, and seeing copious error messages fly across his terminal window*Hmmm, OK, I think someone smarter than me is going to need to figure this stuff out. But I don't have time for that, I want to get my FogBugz up and running so I don't have to switch back to Tiger just to answer customer e-mail. If I could just force Apache to run as 32-bit instead of 64-bit, it should be able to load this PHP module just fine. Now let's see, what would Dr. 90210 do...?[bw-mbp:~] bwebster% man lipoYes, this is extremely hacktackular, and I'm sure there must be a better way to do this, but this is what I got.[bw-mbp:~] bwebster% cd /usr/sbin[bw-mbp:~] bwebster% sudo cp httpd httpd-fat[bw-mbp:~] bwebster% sudo lipo httpd -thin i386 -output httpdAfter making a backup of the httpd executable for safety purposes, the lipo commands sucks out all of the architectures included in the universal binary except the 32-bit Intel one (specified by "i386"). Apache can't run as 64-bit if it doesn't have a 64-bit binary!After doing this, starting up the web server again worked just fine, and loaded the existing 32-bit PHP5 module. Once I got all my httpd.conf customizations moved over to the new location, that was pretty much all I needed to do. It also turns out that I probably would have run into this same problem for FogBugz specifically, since it loads its own fogutil.so PHP module which is also only available as 32-bit right now. I don't know for sure, but I'm guessing people running on G5s, which also support 64-bit, would probably need the same trick, except replacing "ppc" for "i386".This is obviously a very poor long term solution, but if anyone needs to get FogBugz up and running on Leopard right away, this did the trick for me. Ultimately, getting FogBugz to work hack-free will require someone to get a 64-bit build of the PHP5 Apache module figured out, as well as Fog Creek providing a 64-bit build of their own Apache module. And of course what I've outlined here is totally unsupported by Fog Creek, so proceed at your own risk!