Why I like 'lib64' better than 'lib32' for the x86_64 transition

July 12, 2006

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.)

Written on 12 July 2006.
« Why nofollow is useful and important
A thought on Linux installation versus Solaris 9 installation »

Page tools: View Source, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Wed Jul 12 02:23:01 2006
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.