I had a user ask me how to run 32 bits apps on a 64 bit Red Hat server.

I did some searching and found that I need some modules loaded. Not sure where to get them. I cannot just do an update on the RH server as its behind a secure firewall. I need to download them then ftp the over and install manually.

I thought I needed this package but I have an x86_64 kernel loaded.

http://www.cyberciti.biz/tips/how-do...hat-linux.html

So this wont help me. My other searches have not been to fruitful.
HWD is an IBM server.
Uname -a
Linux myserver 2.6.18-92.el5 #1 SMP Tue Apr 29 13:16:15 EDT 2008 x86_64 x86_64 x86_64 GNU/Linux


Thanx

This is the error we are getting when we try to run the application.

[root@myserver tsom] # opsec/bin/LeaDataSource .opsec_config
opsec/bin/LeaDataSource: error while loading shared libraries:
libelf.so.1: wrong ELF class: ELFCLASS64
[root@myserver tsom] #

Hi.

I'd install elfutils-libelf-xx.xx.xx.i368.rpm to hopefully get round the ELF class problem (although, I've never seen an app fail with that error on x86_64).
After that, I'd imagine that you'll need various other i386 (or 1586) libraries installed - you should be able to work through it by running the app, and seeing which xyz.so.1 files it falls over on, and hitting http://rpm.pbone.net to search for which package provides that file, then install the i386 (or i586) version of that package.

You might get some joy from running 'ldd opsec/bin/LeaDataSource' and see if any libraries are 'not found'.

Dave

I can't tell if you understand. That package is for ia64. You have x86_64 in which 32 bit mode support is there by default. You don't need to add any package for the basic 32 bit support.

You do need to have all the 32 bit .so files that the application needs.

I've never see that failure. I don't quite understand it. I thought that was a malfunction you would see running 32 bit applications in 64 bit Windows but Linux is smarter.

We often have both a 64 bit and 32 bit version of the same named .so file (or for Windows the same .dll file). If both are in the search path (LD_LIBRARYPATH in Linux) Windows will find whichever is first in search sequence and if it is the wrong size fail. Linux will find the first one and if it is the wrong bit size skip it and continue the search and find the second one.

I'm not sure what is different about your program or environment that it finds the 64 bit .so and complains about it.

In what I think is the same situation, my experience is it skips the 64 bit .so and then complains that the .so wasn't found.

Clearly the first thing to do is install the required 32 bit .so file. That is all I have needed to do. But your error message makes it seem that you might also need to make sure the 32 bit one is found before the 64 bit one in search sequence.

That's a nice link and I just bookmarked it for any situations in which the yum provides command fails to give me the info I need. But can you tell me why that web page might be your first choice before even trying yum provides?

From my limited knowledge I think yum provides would be a better (specific to the version and repositories you have configured) normal method for answering the question "which package provides the specific file that is missing at the moment".

I also find ldd is a better first line method for finding out which .so files I'm going to need. After I've gotten all the .so files that ldd tells me I will need, then I use the error messages from trying to run the application to tell me about any other .so files I really need.

I'd always use 'yum provides' (unless I was looking for a package I knew wasn't in the repos). The OP said he was behind a firewall, and he has to manually copy files over, so I'm assuming yum will be inoperative for him.

I'm not sure how ldd handles mixed architectures, so I was a bit hesitant to mention it at all. I should really play on my x64 box more often...

Dave

The OP is lucky that you read his post more carefully than I did and you also knew the alternate method. I'll try to read more carefully next time.

here is the output of the ldd command. I guess I have to one of these files to make it work.

ldd LeaDataSource
linux-gate.so.1 => (0xffffe000)
libresolv.so.2 => /lib/libresolv.so.2 (0x0038b000)
libdl.so.2 => /lib/libdl.so.2 (0x00357000)
libpam.so.0 => /lib/libpam.so.0 (0xf7fe3000)
libnsl.so.1 => /lib/libnsl.so.1 (0xf7fcc000)
libelf.so.1 => not found <<<<< Looks like that is the missing file if i read this right.
libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0xf7f12000)
libc.so.6 => /lib/libc.so.6 (0x00212000)
/lib/ld-linux.so.2 (0x001f4000)
libaudit.so.0 => /lib/libaudit.so.0 (0xf7efd000)
libm.so.6 => /lib/libm.so.6 (0xf7ed6000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x0044a000)

RH provided this feed back but I dont have any clue what they are talking about... I guess Ill have to try it. This still does not address the missing fileset.

You may use "linux32" or "setarch" command in RHEL to change reported architecture in new program environment and set personality flags.

e.g:
===
# arch
x86_64
# linux64 bash
# arch
i686
===

As shown above this will report the architecture of a 64 bit system as 32 bit. Certain applications be can be run this way by changing the reported architecture.

NOTE:
I see they had a type from RH i tried linux32 bash and it changed the 64 kept it the same.

Are we correct to assume you can't use Yum because of the firewall? This would be a lot easier with Yum.

I used Yum on Centos 5.3 to find which RPM you would need for Centos 5.3 (I asked yum what provides libelf.so.1 and it told me elfutils-libelf-0.137-3.el5.i386.rpm).
Then I googled that RPM name getting back to the same site ilikejam suggested
http://rpm.pbone.net/index.php3/stat....i386.rpm.html

If your Red Hat system is close enough to Centos 5.3 you could download that .rpm file and get the .so you need from it.

Then I tried the search page ilikejam suggested so I could try RHEL5 in case that is different from my Centos 5.3 and assuming that is what you have (you were a bit ambiguous and inconsistent about what distribution you have) but I couldn't get the search to work.

They are talking about a different issue entirely and I hope they are mistaken about it being something you need to do.

In any case you need to get libelf.so.1 installed. What they are suggesting is in addition to, not instead of getting libelf.so.1.

I don't know how to install from an RPM other than through Yum with a direct internet connection to the repository. But anyone who knows a decent amount about Red Hat admin should be able to tell you how to install from a downloaded RPM file.

If you have RHEL5 I think you can safely use the Centos 5.3 RPM file that I linked to above. But maybe ilikejam will jump in soon with a better suggestion.

You could also try that search yourself (from the link ilikejam posted) especially if I misunderstood and it isn't RHEL5.

Edit: My local Centos expert just told me: After you download
elfutils-libelf-0.137-3.el5.i386.rpm
switch to root and

The machine is REL5. Sorry if I was not clear on that. I did do a search as suggested. Just trying to figure out what version of the file i needed. Many came back. I dont know about the elfutils-libelf-0.137-3.el5.i386.rpm for Centos 5.3. Was looking for a RHEL5 fileset.

RH has been slow to respond. Once I hear back Ill let you know.

we are behind a FW so I have no YUM access. I have to download manually. It would be much easier to have internet access but this will not happen.

Thankx for all the good suggestions. I appreciate it.

CJ

Question : How did you "(I asked yum what provides libelf.so.1 and it told me elfutils-libelf-0.137-3.el5.i386.rpm)."

Pardon my inexperience, but how do you ask YUM to tell you what filesets are in what .rpm? Especially if you don't have the .rpm file loaded.

Or are you saying you have to rely on someone that has what you need to be able to find out what .rpm has it included in it?

just a little confused by the statement.
I am guessing someone with the file son their system has to run

yum list or provides option? or some switch like resolve? I dont do much with yum just yet.

Centos 5 is supposed to differ from RHEL5 only in some names and logos. I don't think there are any such names or logos in elfutils-libelf so I think you should be OK using the version Centos would use.

I typed and it gave the answer.

Yum looks in some kind of index that it downloaded from the repositories. This search is not limited to packages that are installed on the current system.

Cool i appreciate that info.. This is what I got back form RH. I just thought i would post it in case someone else runs into this issue

#yum whatprovides *libelf.so.1

For a RHEL4 box you need to use the following command:

#up2date --whatprovides "libelf.so.1"

To install elfutils-libelf package you need to login to RHN, go to the 'download software' area. Select the "Red Hat Enterprise Linux (v. 5 for 32-bit x86) " channel. In packages section, search for the package elfutils-libelf. Once you have downloaded the rpm, you can install it using the command 'rpm -ivh elfutils-libelf-0.137-3.el5.i386.rpm'. The direct link for this package is given below:

https://rhn.redhat.com/rhn/software/....do?pid=469495

You can also install the 32bit version of the same package via command line using yum.

#yum install elfutils-libelf.i386

Once this is installed you can re-check it using the following command:

#rpm -qa --qf "%{name}-%{version}-%{release}.%{arch}\n" | grep elfutils-libelf
elfutils-libelf-0.137-3.el5.x86_64
elfutils-libelf-0.137-3.el5.i386

#rpm -ql elfutils-libelf-0.137-3.el5.i386 | grep libelf.so.1

Well Im back with another question. 3 out of 4 systems worked fine I now see....

rpm -ihv libselinux-1.33.4-5.5.el5.i386.rpm
warning: libselinux-1.33.4-5.5.el5.i386.rpm: Header V3 DSA signature: NOKEY, key ID 897da07a
Preparing... ########################################### [100%]
file /lib/libselinux.so.1 from install of libselinux-1.33.4-5.5.el5 conflicts with file from package libselinux-1.33.4-5.el5


I got the file from http://rpm.pbone.net/index.php3?stat...3.el5.i386.rpm

Interesting thats for sure.

Hi.

Try 'rpm -Uvh' instead of 'rpm -ivh'.

Dave