I found on the web:
Unlike Debian based distributions, Red Hat and distributions based on it
organize lib directories in a way that lets you install a 32 bit package
of .so files on an x86_64 system without any conflict with the 64 bit
build of the same package, which may also be installed.
AND:
The Debian system dynamic library linker has been modified so that when
a 32-bit application requests access to a library, Debian provides the
32-bit version of the library if it is available instead of the normal
64-bit version that the native applications require. This works if the
ia32 packages which provide a sub-set of standard Debian libraries
compiled in 32-bit mode have been installed. (NB: I am not using a
Debian distro, but the SL 6 RHEL 6 distro. The quote is for clarity.)
End quote.
Unfortunately, this does not always seem to be the case in direct
practical experience.
Two questions:
1. How to install the SL6 release so that the System -> Administration
-> Add/Remove Software will list both the 64 bit and 32 bit libraries?
I have tried sl-release-6.0-6.0.1.i686.rpm and this does not cause these
library choices to be displayed.
I suspect this is because from the sl.repo file, the stanza
name=Scientific Linux $releasever - $basearch always puts the actual
base kernel ISA into the $basearch, so only X86_64 appears. I tried to
make a separate repo file that would force the IA-32 libraries to be
listed, and although I enabled the new repo using System -> Software
Sources in the Add/Remove Software application, no such library RPMs
appeared.
2. Many packages that must be built from source rely upon configure and
for various reasons, paths such as /usr/lib , not /usr/lib64 that is the
X86-64 path, appear. This is an issue with appropriate scope specific
polymorphism. Will the following idea address this issue? Two unique
paths for libraries and include files: foo32 and foo64 with foo being
the appropriate path identifier. At the actual time when a decision as
to which foo to use, set foo to either foo32 or foo64 but let the
application (e.g., configure and the files needed for configure to
"configure") only find foo . Thus /lib could be either /lib32 or /lib64
depending upon whether a 32 or 64 bit application was needed, etc. This
is still much simpler than a chroot mechanism of keeping two identical
operating systems and application environments on the same machine, one
IA-32 and the other X86-64. Obviously, utilities such as ld (mentioned
in a Debian context above) must be aware of the differences, as must
compilers when creating appropriate object or executable file internal
headers.
Yasha Karant
- SL 6 IA-32 and X86-64 polymorphism Yasha Karant
-
