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.)
Comments on this page:
|
|