== Why I like 'lib64' better than 'lib32' for the [[x86_64|]] transition One of the small controversies in Linux on the '[[x86_64|]]' architecture is where 'native' 64-bit libraries should go, versus where 'legacy' x86 libraries should wind up. One version is what Fedora Core does, putting 64-bit libraries in _/usr/lib64_; the other version is what Debian does, where legacy x86 libraries go in _/usr/lib32_ and _/usr/lib_ is for 64-bit binaries. (Some distributions use more complicated paths than _/usr/lib32_.) I used to be pretty neutral on this whole issue, but then I got an AMD64 machine and started playing around in the whole bi-arch world. Now I think the 'lib64' approach is the right way. What it comes down to for me is that [[x86_64|]] is not really a new architecture; it is effectively an upgrade of the existing x86 architecture. (It being an upgrade instead of a wholesale replacement is why it's interested to start with; I have little desire to jettison all of my x86 programs in a great big lurch. Been there, done that, it's a pain.) The 'lib64' approach is the right one for an upgrade, because it leaves the old stuff alone and puts the new stuff in a new place. It's even possible to (re)use x86 RPM packages directly, since they install in the same place (and work the same) regardless of whether they're running on an x86 OS or an [[x86_64|]] one. This can't be done on a 'lib32' system; you need to rebuild x86 packages for [[x86_64|]] just to make them put libraries in _/usr/lib32_ instead of _/usr/lib_. (I suppose you could put a bunch of magic into your packaging system, but this soon starts to get ugly.)