On Mon, 2011-06-27 at 22:32 +0100, Yasha Karant wrote: > 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
In add/remove software you need to uncheck the filter "only native packages"
