Ambassador

It takes some time, patience, some hacking, Google...

After 1 full day (as in 24 hours), I am confused but got all my (required) binaries have Intel 64-bit Mach-O binary. Apache2 is running on x86_64. I need a simple photo album. It turned out that I didn't compile PHP5 with PostgreSQL support at the time (no, I don't use MySQL - I am a PostgreSQL user). Actually, it turned out that my compiled PHP never loaded with existing Apache2! (ouch! too late, but I realized it way too late) To compile PHP with PostgreSQL support, one needs to compile PostgreSQL first, of course. But even before that...

Fink - does fink need a spank?
Sorry, but - WTF? Why don't we get universal binaries of libraries at least? Some dudes seem like objecting universal binaries with groundless claims; "because it takes long to compile and requires more space, blah blah...". The difference between an just fat but always workingbinary and sometimes, may be working binary is huge. If you want to provide proper service, former is better. Besides, latter doesn't necessarily work always. That is, if one needs to link a library obtained with fink against a x86_64 binary, that won't work. The cost of a universal binary (space + compile time [which is completely negligable, at least on my quad Mac Pro]) <= pile of bytes that can't link (which is what you get from fink).

Same happened during my OpenSceneGraph hacking adventures as well. Nearly, none of my fink generated libraries worked. Because I generated osg for x86_64 and i386, and I always prefer 64-bit. Why? Because I love big numbers! Don't be dumb!

Currently, nearly nothing is installed from fink. Actually, I consider removing it completely, as it causes more confusion than it aims to solve.

Compiling PostgreSQL
This was somewhat painful. First of all, PostgreSQL depends on some third party libraries. I have also added xml2 support, which required libxml2 to be compiled for multiple architectures as well. During libxml2 compilation, I built few more GPL'ed stuff. After all dependencies are built and installed, it's now time to compile a Mach-O fat file that contains both i386 and x86_64 binaries (in theory).

But it can't be as easy as just a configure-make sequence! It turned out that PostgreSQL configure or make or something I don't exactly know, generates a file (pgconfig.h?) which holds some information about types, sizes, etc. I never saw contents of the file, but my compilation error and Google search shown that there is a generated file, which can't be used for multiple architectures. Duh!

Building PostgreSQL is much like building any other strangely (and wrongly) configured open source app; run configure each time for each architecture, store binaries separately then merge them with lipo (I used --exec-prefix=/full/path/i386_or_x86_64). If you are lucky, this works as expected.

Building PostgreSQL and its dependencies with x86_64 support took roughly 4 hours. Building PostgreSQL (configure and make) takes quite short. I think it's around 2 minutes. However, after each build, I need to link other modules, test with existing database, restart (for some sysctl modifications), etc.

Wrong built MySQL
My previous MySQL build, also, turned out that only x86_64. This was totally my mistake. It took quite short to get mysql built and installed (with additional i386 as well).

libjpeg - ancient
It took time to build libjpeg, despite the fact that I did it before. I keep forgetting what I did with it... I think I have hacked makefile at the end.

png
libpng took short as well.
GD
GD took some time due to dependencies.
iconv
fink said "iconv is critical" and it didn't remove. Well, removing fink completely was easier. I built libiconv for both Intel architectures.
PHP5
This took long time. xml2 and iconv caused trouble. Then postgresql didn't start. Then, I realized I didn't pass --with-apxs2, which meant it didn't build libphp5.so for Apache2. After PHP was built, I checked my configuration and it turned out that I don't have gettext support! Going back and rebuilding gettext and its dependencies, then PHP5 again.

After roughly 24 hours, it all worked fine. I vaguely remember that day. I hope that doesn't repeat again.

I would like to let Mac OS X devs to understand this simple fact of our lives; if you want to distribute something, prefer Universal Binary (for roughly 6-7 years more, until Apple drops all previous architectures, including i386). Whether it's big in byte-size doesn't necessarily affect its portability/functionality. See, portability is one of the major concerns of software developers for ages. Please distribute "working" copies, not "works for me" copies of libraries at least. They are libraries for God's sake! Any other binary may depend on those and when that fails to link (during linking or at run-time), people may waste a lot of time. If you want to save time of others, do it properly.