How do shared libraries work in a mixed 64bit/32bit system?

user_40401 0
Viewed 22918

Good morning,

on a 64bit RedHat box we have to compile and run a 32bit application. Meanwhile I managed to compile the gcc version needed (4.0.3) and all required runtime libraries in 32bit and have set the LD_LIBRARY_PATH to point to the 32bit versions, but now during the remaining build process, a small java program needs to be executed which is installed in /usr/bin as a 64bit program, which now finds the 32bit version of libgcc_s.so first.

In general, if I set the LD_LIBRARY_PATH to the 32bit versions, I break the 64bit programs and vice versa.

How it this supposed to work at all? I am certain I am not the first person with this problem at hand. How is it solved usually?

Regards, Stefan

64-bit shared-libraries linux
5 Answers

I have faced this exact same problem when remastering a 32bit tinycore64 system running a 64bit kernel.

After much searching, I have discovered why these comments would make sense to both of them.

"That would be nice, but - at least in my environment - it did not appear to work. The loader did complain; it did not simply skip the libraries that do not match the bit-ness. Sadly!" - struppi

"This is very strange, could you describe how things failed? Also, perhaps post the output of ldd?" - Adam Goode

And why this comment might appear to be true but is actually incorrect.

The linker will ignore the libraries that it cannot read.

This link shed's some light on it. http://www.markusbe.com/2009/09/about-running-32-bit-programs-on-64-bit-ubuntu-and-shared-libraries/

And more to the point, you will find the ld.so manpage enlightening.

It turns out the path name can make a difference in what the runtime linker ld.so chooses as the library to load. On my 64bit linux system I have a range of odd directory names in addition to the standard ones. e.g. /lib/x86_64-linux-gnu. I actually thought I'd experiment by moving the libraries in that path to /lib64. When I did that, guess what happened? suddenly my 64bit app (brctl in this case) didn't work and complained with "Wrong ELF class". Hello... now we're onto something.

Now I'm not 100% certain but the key seems to be related to rpath token expansion. I suspect the ${PLATFORM} expansion may have something to do with it. And the name x86_64 must be part of that.

In any case, I found when I put my 64-bit libraries in library paths named x86_64-linux-gnu as apposed to just lib64, then they were preferred over the 32bit ones and things worked.

In your case, you probably want to do something very similar for 32bit libraries on 64. Try i386-linux-gnu.

So in my case where I am installing 64bit shared libraries onto a 32bit userland, I created the following paths:

mkdir /lib/x86_64-linux-gnu/
mkdir /usr/lib/x86_64-linux-gnu/
ln -s /lib/x86_64-linux-gnu /lib64
ln -s /usr/lib/x86_64-linux-gnu /usr/lib64

Add your 64bit libraries to the 64bit paths and 32bit libraries to the 32bit /lib & /usr/lib paths only.

Then add the 64bit specific paths to ld.so.conf and update your cache with ldconfig Now your 32-bit & 64-bit applications will run seamlessly.

user_1347020
Related