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"