18

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

Adam Goode
  • 7,380
  • 3
  • 29
  • 33
struppi
  • 595
  • 1
  • 3
  • 15

5 Answers5

14

Add both the 32-bit and 64-bit directories to the LD_LIBRARY_PATH.

If you do this, then the ld.so for 32-bit or 64-bit will use the correct libraries.

e.g. A 32-bit test app "test32" and 64-bit test app "test", with a locally-installed copy of a (newer version of) gcc and binutils in a user homedir, to avoid clobbering the system-wide install of gcc:

=> export LD_LIBRARY_PATH=/home/user1/pub/gcc+binutils/lib:/home/user1/pub/gcc+binutils/lib64

=> ldd ./test32
    libstdc++.so.6 => /home/user1/pub/gcc+binutils/lib/libstdc++.so.6 (0x00111000)
    libgcc_s.so.1 => /home/user1/pub/gcc+binutils/lib/libgcc_s.so.1 (0x00221000)

=> ldd ./test
    libstdc++.so.6 => /home/user1/pub/gcc+binutils/lib64/libstdc++.so.6 (0x00007ffff7cfc000)
    libgcc_s.so.1 => /home/user1/pub/gcc+binutils/lib64/libgcc_s.so.1 (0x00007ffff7ad2000)

(Less interesting library paths removed)

This shows that the loaders know to ignore the libraries of the wrong architecture, at least on this Scientific Linux 6.3 (RHEL-derived) system. I would expect other distros to work similarly, but haven't tested this.

This may have only started being the case more recently than your (unspecified) distro version, however.

David Gardner
  • 6,952
  • 4
  • 35
  • 37
3

On Solaris one can use LD_LIBRARY32_PATH and LD_LIBRARY64_PATH, but that isn't supported on Linux.

In general, you should just never need to set LD_LIBRARY_PATH at all in the first place:

  • either install needed libraries into /usr/lib32 or /usr/lib64 as appropriate, or
  • build your 32-bit application with -Wl,-rpath=/path/to/32-bit/libs
Employed Russian
  • 199,314
  • 34
  • 295
  • 362
2

As a workaround, wrap the Java call in a small shell script which unsets LD_LIBRARY_PATH and then calls the executable. Alternatively, this might also work:

LD_LIBRARY_PATH= java...

Note the space between "=" and the name of the executable.

Aaron Digulla
  • 321,842
  • 108
  • 597
  • 820
  • Thanks for the idea, it will probably work in this particular case. I was however looking for a more generalized approach, which doesn't require to change the build scripts on the machine. – struppi Nov 10 '09 at 09:38
  • Yes; I'm not sure how the automatic pickup works. I suggest to install a 32bit app and run "ldd" on it. If that picks of the libraries, then it must be some magic happening in /etc/ld.conf and ldconfig: http://linux.die.net/man/8/ldconfig – Aaron Digulla Nov 10 '09 at 10:20
0

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.

Community
  • 1
  • 1
hookenz
  • 36,432
  • 45
  • 177
  • 286
0

Just set LD_LIBRARY_PATH to both paths (use colons to delimit). The linker will ignore the libraries that it cannot read.

Adam Goode
  • 7,380
  • 3
  • 29
  • 33
  • 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 Nov 13 '09 at 20:23
  • This is very strange, could you describe how things failed? Also, perhaps post the output of `ldd`? – Adam Goode Nov 13 '09 at 21:01