On Sun, Feb 19, 2006 at 04:12:06PM -0500, Daniel Hagerty wrote:
>> It doesn't exactly say that, but its requirements for 32 bit
>> binaries and 64 bit binaries conflict, if I remember well. Like
>> they both can expect their libraries to dlopen() to be in /usr/lib/
>> or something like that. Only on some 64 bit architectures. Not all
>> of them. I don't remember the details.
> This is not a conflict given engineering effort. 32 bit
> binaries and 64 bit binaries are distinguishable from one another,
> and your kernel can take appropriate steps to get them to coexist.
It can, but this leads to either a different filesystem view for 32
bit and 64 bit binaries, or different system calls not acting on the
same file when given the same filename; I find the two
unattractive. The first means that typing "objdump -x /lib/foo.so"
will give different results depending on whether you installed the 32
bit objdump or the 64 bit one. The second means that code like:
if (access("/usr/lib/foo.so", R_OK))
dlopen("/usr/lib/foo.so")
not to do what one expects at first.
There are efforts in the direction of solving the problem cleanly by
changing all this to a scheme so that 32 bit IA32 libraries for
glibc/linux live in /usr/lib/i386-gnu-linux/, 64 bit sparc libraries
glibc/(kernel of FreeBSD) live in /usr/lib/sparc64-gnu-freebsd/, ...
so that whatever your processor can execute (and whatever your kernel
can "emulate"), parallel installation is not an issue. This
"obviously" breaks all legacy applications (except for _one_
architecture per filesystem, with symlinks), which are ... like the
major point of the LSB. Politics, politics, politics.
> It might help you to remember that amd64 is not the first platform
> to have these sorts of issues; sparcv9 is a decade old and presented
> similar problems with sparcv8 executables.
The LSB is more reasonable for sparcv9: 64 bit libraries are in
/usr/lib64/, if I remember well. Usually the base system is a 32 bit
one (thus taking the special names /usr/lib/, etc), with support for
64 bit binaries (with _other_ paths like /usr/lib64/). I don't think
any distro makes a "full native" sparc64 port. Because in amd64 you
get double amount of registers compared to IA32 (and maybe for stoopid
marketing reasons: we support a native 64 bit system!), it was usually
decided to make a "port" of distros where the base system a 64 bit
one, thus taking the special /usr/lib/ paths. Messy, messy, messy.
This all doesn't help for truly 64 bit-only targets like alpha (unless
you do real CPU emulation). OTOH in 5 years, alpha will be irrelevant
anyway. :)
--
Lionel
|