The rpm utility does not resolve any software dependencies and is not the recommended tool to install software since RHEL 5. You can use the yum utility instead, which automatically resolves software dependencies.
If you do not specify the platform architecture, yum will select the appropriate package for the current platform. Since software libraries are usually backward compatible, you should not specify a particular version, unless it is absolutely necessary.
In your case:
yum install binutils compat-libcap1
yum install compat-libstdc++-33 compat-libstdc++-33.i686
yum install gcc gcc-c++ glibc glibc.i686
yum install libio libaio-devel libstdc++ libstdc++.i686
[root@vm21 ~]# yum install glibc.i686
Loaded plugins: security
Setting up Install Process
--> Running transaction check
---> Package glibc.i686 0:2.12-1.107.el6_4.5 will be installed
--> Processing Dependency: glibc-common = 2.12-1.107.el6_4.5 for package: glibc-2.12-1.107.el6_4.5.i686
--> Processing Dependency: libfreebl3.so for package: glibc-2.12-1.107.el6_4.5.i686
--> Processing Dependency: libfreebl3.so(NSSRAWHASH_3.12.3) for package: glibc-2.12-1.107.el6_4.5.i686
--> Running transaction check
---> Package glibc-common.x86_64 0:2.12-1.107.el6_4.4 will be updated
--> Processing Dependency: glibc-common = 2.12-1.107.el6_4.4 for package: glibc-2.12-1.107.el6_4.4.x86_64
---> Package glibc-common.x86_64 0:2.12-1.107.el6_4.5 will be an update
---> Package nss-softokn-freebl.x86_64 0:3.12.9-11.el6 will be updated
---> Package nss-softokn-freebl.i686 0:3.14.3-3.el6_4 will be installed
Thanks for the prompt reply!
I didn't mean to imply that I'm using rpm to install rpms. I'm not.
I'm using yum, as you suggested.
Your post confirmed the procedure that I thought should be right: if the prerequisities don't explicitly say with platform to install for, just leave it off and one will get the package that corresponds to one's OS.
So in my case "yum install libaio" will fetch the 64-bit version, since I'm running 64-bit RHEL 6.4.
Now here's the follow-up question, and perhaps this should be a SR now:
why is the IAM throwing the following package dependency error?
Checking for libaio-0.3.106-i386; Not found. Failed <<<<
It's obviously looking for 32-bit versions, which I don't have -- I only have the 64-bit version.
Is this a documentation error or did I do something wrong?
That's probably because your installation was designed for an earlier version of the OS, which still supported i386 or Intel 80386 CPU, which is really ancient. As of RHEL release 6 a Pentium Pro, introduced in late 1995 is required, hence i686, which is still 32-bit. The error you are getting is benign. There is probably a "ignore" checkbox somewhere to allow you to continue with the installation.
I hear what you're saying, and I do have some errors of the kind you mention. Errors like this:
Checking for compat-libstdc++-33-3.2.3-i386; Not found. Failed <<<<
This is clearly benign because
yum list installed compat-libstdc++-33
compat-libstdc++-33.i686 3.2.3-69.el6 @/compat-libstdc++-33-3.2.3-69.el6.i686
compat-libstdc++-33.x86_64 3.2.3-69.el6 @c5-media
So the i686 version is there. But
yum list installed libaio
only shows one package
libaio.x86_64 0.3.107-10.el6 @anaconda-RedHatEnterpriseLinux-201301301459.x86_64/6.4
No 32-bit version is available. Nor did the list of pre-reqs call for it.
So what is the problem? Do you think libaio 32-bit should be installed? Libaio provides asynchronous I/O support for the kernel. Since your kernel is x64 you do not need 32-bit libraries. You only need 32-bit libraries on a x64 system it you are building or running a 32-bit application. 32-bit and 64-bit libraries reside in different directories so they do not interfere with each other. The same of course does not apply to applications and core system files.
I admit I didn't bother to look up what libaio was. But if it's not required, why is the installer asking for it? In fact, by that logic, why does the installer need any 32-bit libraries. I mean, I understand what you're saying but I'm just trying to follow what's documented.
Seems like a documentation bug to me....