Not a problem. That works out, cause I need to run to the beer store....

One more thing - Since you brought up the libraries already, see if you have glibc-devel-2.11-2.i686 or similar installed.

How do I check the version of the installed glibc? Below is yum search libc

in /lib I see libc-2.5.so
in /lib64 I see libc-2.5.so as well

Not sure if I see devel libraries.


compat-glibc.i386 : Compatibility C library
compat-glibc.x86_64 : Compatibility C library
compat-glibc-headers.x86_64 : Header files for development using standard C libraries.
cdparanoia-devel.i386 : Development tools for libcdda_paranoia (Paranoia III).
cdparanoia-devel.x86_64 : Development tools for libcdda_paranoia (Paranoia III).
cdparanoia-libs.i386 : Libraries for libcdda_paranoia (Paranoia III).
cdparanoia-libs.x86_64 : Libraries for libcdda_paranoia (Paranoia III).
compat-libcom_err.i386 : A libcom_err compatibility library
compat-libcom_err.x86_64 : A libcom_err compatibility library
curl-devel.i386 : Files needed for building applications with libcurl.
curl-devel.x86_64 : Files needed for building applications with libcurl.
glibc.i686 : The GNU libc libraries.
glibc.x86_64 : The GNU libc libraries.
glibc-common.x86_64 : Common binaries and locale data for glibc
glibc-devel.i386 : Object files for development using standard C libraries.
glibc-devel.x86_64 : Object files for development using standard C libraries.
glibc-headers.x86_64 : Header files for development using standard C libraries.
glibc-utils.x86_64 : Development utilities from GNU C library
kernel-headers.x86_64 : Header files for the Linux kernel for use by glibc
libc-client.i386 : C-client mail access routines for IMAP and POP protocols
libc-client.x86_64 : C-client mail access routines for IMAP and POP protocols
libc-client-devel.i386 : Development tools for programs which will use the IMAP library.
libc-client-devel.x86_64 : Development tools for programs which will use the IMAP library.
libcap.i386 : Library for getting and setting POSIX.1e capabilities
libcap.x86_64 : Library for getting and setting POSIX.1e capabilities
libcap-devel.i386 : Development files for libcap
libcap-devel.x86_64 : Development files for libcap
libchewing.i386 : Intelligent phonetic input method library for Traditional Chinese
libchewing.x86_64 : Intelligent phonetic input method library for Traditional Chinese
libchewing-devel.i386 : Development files for libchewing
libchewing-devel.x86_64 : Development files for libchewing
libcmpiutil.i386 : CMPI Utility Library
libcmpiutil.x86_64 : CMPI Utility Library
libcmpiutil-devel.i386 : Libraries, includes, etc. to use the CMPI utility library
libcmpiutil-devel.x86_64 : Libraries, includes, etc. to use the CMPI utility library
libcroco.i386 : A CSS2 parsing library
libcroco.x86_64 : A CSS2 parsing library
libcroco-devel.i386 : Libraries and include files for developing with libcroco.
libcroco-devel.x86_64 : Libraries and include files for developing with libcroco.
libcxgb3.i386 : Chelsio T3 iWARP HCA Userspace Driver
libcxgb3.x86_64 : Chelsio T3 iWARP HCA Userspace Driver
libcxgb3-static.x86_64 : Static version of the libcxgb3 driver

Check to make sure you have compat-glibc, glibc, and glibc-devel 32 bit libraries installed, among the dependencies they need.

Doesn't RHEL have some 32 bit compatibility libs? On debian, there's a package named ia32-libs that allows you to run 32 bit executables on 64 bit environments... Maybe there's something similar on RHEL? (the name may differ, though).

That's most likely it. I almost got confused between the libraries.

Nothing in that post seems to connect to the issue in the title of the thread 32 bit binaries do not run on 64 bit machine.

Your later post supports the thread title, but even with that later post, it seems to be a leap to conclude your Java problem is the same as your 32 bit problem.

That was pretty convincing that you have some problem with 32 bit executables. A little more investigation might tell us a bit about what the problem is. Start with the output from these two commands:
For comparison, on my Centos system that 32 bit program works and those commands give the output

Hmmm, I would've gotten back to this sooner but I didn't get an email about new comments for some reason..

anyways, I was following corp769's suggestion of installing the latest gcc which requires GMP 4.2+, MPFR 2.3.1+ and MPC 0.8.0+. I'm trying to install them without overwriting the versions I already have installed. I'm a little confused on how to use the rpm's relocate command to accomplish this. Would the following work?

rpm -ivf --relocate /usr=~/usr gmp-4.2.2-8.fc10.x86_64

for johnsfine

[rfriesen@***** c-test]$ file hw32
hw32: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.6.9, dynamically linked (uses shared libs), for GNU/Linux 2.6.9, not stripped
[rfriesen@***** c-test]$ ldd hw32
linux-vdso.so.1 => (0x00007fff5dffc000)
libc.so.6 => /lib64/libc.so.6 (0x000000363aa00000)
/lib64/ld-linux-x86-64.so.2 (0x000000363a600000)
[rfriesen@***** c-test]$

I notice that my "libc.so.6" points to a "/lib64/libc.so.6" whereas yours does not. How can I fix this?

Ahh, linker problems. Looks like you might not have all of the 32 bit libraries installed.... You might have to either manually link your program to 32 bit libraries, which technically is not recommended, or track those 32 bit ones down....

well I see a /lib/libc-2.5.so

is that what should be loaded for this compilation?

There's a lot of confusion in this thread:

1. The initial post seemed to have NOTHING to do with 32- vs 64-bit, and EVERYTHING to do with the correct syntax for invoking a Java program with the correct .jar. Please revisit that at some point before closing this thread.

2. In general, 32-bit apps CAN and DO run without any problem on 64-bit OS's.

The "magic" that allows this to happen is installing parallel 32- and 64-bit runtime libraries (including, but not limited to, libc).

Most 64-bit distros install both by default. Some don't. The problem often manifests itself when people try using the Android SDK on a 64-bit OS. A common solution is some variation of this:
3. Please cut/paste your exact "hello world" source, compile command and command line output now that you've updated your libraries. If anything's wrong, please run "file hw*" and "ldd hw*" on your "hw" executables, and cut/paste the results.

Thanx in advance .. PSM

Do you have a suggestion on how to install ia32-libs using yum?

Those are all three wrong. So the next step is to see whether the correct files are missing vs. something else went wrong during linking.

So start with
I'm not sure where linux-gate.so.* is supposed to be.

I'm not at a Centos system now, so I can't experiment with yum commands. When a file isn't present, the "yum provides" command generally tells you the package you could get it from. Something like

[rfriesen@2 ~]$ ls -l /lib/libc.so.*
lrwxrwxrwx 1 root root 11 Feb 25 09:35 /lib/libc.so.6 -> libc-2.5.so
[rfriesen@~]$ ls -l /lib/ld-linux.so.*
lrwxrwxrwx 1 root root 9 Feb 25 09:35 /lib/ld-linux.so.2 -> ld-2.5.so

a "sudo find / -name linux-gate.so.*" turned up empty?

So it isn't something simple such as those two .so file missing.

I didn't actually know what linux-gate was before myself. I never looked at that detail of ldd before. Even on my Mepis system, ldd shows linux-gate.so.1 and locate can't find it. So with google I found
http://www.trilithium.com/johan/2005/08/linux-gate/
That explains why I see linux-gate.so.1 from ldd. It doesn't explain why you see the 64bit version for your 32 bit executable.

I'm getting a bit out of my depth on link time problems, but we should at least look at the info gcc passes to the linker. So try this (output is fairly large):
Probably, but what linker problem and why?

The indications are pretty clear that the only 32 bit .so files required for this example are /lib/libc.so.6 and /lib/ld-linux.so.2 and the OP showed both are present.