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


Comments on this page:

From 74.12.143.77 at 2006-07-12 08:07:29:

Solaris has dealt with 32/64-bit compatibility for about 10 years or longer. The 64-bit libs reside in a separate directory, e.g. /usr/lib/sparcv9, while the 32-bit libs remain in /usr/lib for compatibility. Similarly for Solaris_x86.

Oscar@MIE

From 67.181.30.74 at 2006-07-12 13:16:07:

There is no controversy, not even a small one. It's very clear that Debian made an awful mistake. It was caused by the lack of multiarch support in dpkg and general lack of direction and architecture in the distro. They have a bunch of brilliant hackers, each fortified in his little package fortress, and no good people with the overarching scope of thinking.

It is the same error which ia64 upstream committed, by the way. It always happens if developers think of compatibility as an add-on.

-- Pete

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

Page tools: View Source, View Normal.
Search:
Login: Password:

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