Mountain Lion eliminates 32-bit code from a number of libraries, so YMMV for 32-bit code that links to private frameworks and random stuff in /usr/lib.

libpq.dylib is a actually a good example I ran into myself (using Python packages I had installed myself under Lion with pip): a fat binary in 10.7, but 64-bit only in 10.8. Quick fix if you've installed a fat libpq elsewhere: for each Mach-O binary that links to /usr/lib/libpq.dylib, install_name_tool -change /usr/lib/libpq.dylib /path/to/fat/libpq.dylib /path/to/binary This only works if your fat version is binary compatible with the pre-upgrade version, of course. If this command has no effect, verify the exact original path specified in the binary via otool -L /path/to/binary because, AFAIK, install_name_tool requires an exact match. The "preferred" solution is to rebuild whatever broke, making sure that it links against the right libpq in the first place, of course.

Note that this problem shouldn't affect tools bundled with a freestanding PostgreSQL installation, as they'll (presumably) be linked against the correct version already, nor tools installed by MacPorts, as they'll link to /opt/local/lib/libpq.dylib, but if things you've built and installed yourself start failing with "wrong architecture" errors from the dynamic loader, this is a likely cause. I've never used Homebrew, so I have no idea what it links against.

They mostly work as it is, things like imagemagick you need to recompile and reinstall dependent gems

But first update Xcode and the command line tools

I'd like to know that myself. I'm pretty sure homebrew should be okay (for the most part, and when it's not, just "brew update" it), but am not 100% sure. Sadly I don't remember what happened when I upgraded from Snow Leopard to Lion, and homebrew's homepage on github doesn't say much about the transition.