0

I have a binary which needs some *.so files to execute. Now when I try to execute it on some older machines it shows

/lib/libc.so.6: version `GLIBC_2.4' not found

how can I change its search path to /lib/i386-linux-gnu/libc.so.6 from /lib/libc.so.6

So I can run two different libc files on a same machine.

Cong Wang
  • 2,001
  • 12
  • 13
Jatin Bodarya
  • 1,425
  • 2
  • 20
  • 32

3 Answers3

0

Are you on a 32-Bit system and maybe trying to execute a binary that uses the 64 bit glibc?

Modifying the library search path can be done by using LD_LIBRARY_PATH variable, e.g. in a subshell:

(export LD_LIBRARY_PATH=/lib/i386-linux-gnu:${LD_LIBRARY_PATH}; my_program)

mats
  • 1,818
  • 3
  • 18
  • 26
  • actualy I have implemented it on ubuntu 12.04 ldd -version=2.15 and I suppose to execute it on uname -a =Linux manage 2.6.39.4-1smp and ldd version 2.2.4 – Jatin Bodarya Jan 17 '13 at 08:30
  • /bin/sh: /lib/ld-linux.so.2: version `GLIBC_2.3' not found (required by /lib/i386-linux-gnu/libc.so.6) /bin/sh: /lib/ld-linux.so.2: version `GLIBC_PRIVATE' not found (required by /lib/i386-linux-gnu/libc.so.6) – Jatin Bodarya Jan 17 '13 at 10:06
  • Did you compile the program complaining about GLIBC yourself? If so, could you provide compile and linker flags? Perhaps adding some flags along the lines of `-m32` might help (assuming gcc is used). – mats Jan 17 '13 at 11:53
  • these problem re almost solved... can I use this temp. path as permanently ? some programs are working on old lib and some on newer one – Jatin Bodarya Jan 17 '13 at 12:49
  • You could export the working LD_LIBRARY_PATH definition by adding `export LD_LIBRARY_PATH=/lib/i386-linux-gnu:${LD_LIBRARY_PATH}` (or in csh: `setenv LD_LIBRARY_PATH /lib/i386-linux-gnu:${LD_LIBRARY_PATH}`) to /etc/profile or $HOME/.profile or similar files that set up your environment ($HOME/.profile obviously will only affect your current user). – mats Jan 17 '13 at 13:13
  • i have files /lib/i386-linux-gnu/libc.so.6 and /lib/libc.so.6 . mostly binary uses the second file as it is original system file...and I want some binary or .so files that should use the first one. Is there any possiblity to establish any crush ? as both file names are same So may be all binary goes to the first option rather than second !! – Jatin Bodarya Jan 18 '13 at 05:04
  • In that case you could write a shell script which has the same name as one of the exceptional binaries using i386 glibc. The script sets the first search path in LD_LIBARY_PATH to /lib/i386-linux-gnu and executes the program that exceptionally useses the i386 version of glibc. A wrapper, in other words. The directory containing your wrapper scripts can be published by adding it to PATH the same way as was suggested for LD_LIBRARY_PATH. – mats Jan 18 '13 at 08:05
0

You can change the search path by using the LD_LIBRARY_PATH environment variable when calling your binary.

Something along the lines of:

LD_LIBRARY_PATH=/lib/i386-linux-gnu/libc.so.6 ./your_binary

should work. Bear in mind that depending on the shell you're using you might need to call either export or env to set the variable.

You can check if it's working using the following command:

LD_LIBRARY_PATH=/lib/i386-linux-gnu/libc.so.6libc.so.6 ldd ./your_binary
        linux-vdso.so.1 =>  (0x00007fff140e9000)
        libselinux.so.1 => /lib/libselinux.so.1 (0x008f9000)
        librt.so.1 => /lib/librt.so.1 (0x006f1000)
        libacl.so.1 => /lib/libacl.so.1 (0x004e8000)
        libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0x00129000)
        libdl.so.2 => /lib/libdl.so.2 (0x00f25000)
        /lib/ld-linux.so.2 (0x003b3b000)
        libpthread.so.0 => /lib/libpthread.so.0 (0x00d07000)
        libattr.so.1 => /lib/libattr.so.1 (0x00b02000)

You just need to check if libc.so.6 is being resolved to the shared object that you want.

UPDATE: It seems that you want to load a 32 bit shared object for a 64 bit binary. As far as I know there is no way to do this since the target architectures are different and the loader will refuse to load the 32 bit so. If this is your case, this might explain why the loader loads the default libc. Depending on your case, it might be possible to compile the binary as 32 bits, in which case it should run with a 32 bit libc.

Alberto Miranda
  • 382
  • 6
  • 16
  • LD_LIBRARY_PATH=/lib/i386-linux-gnu/libc.so.6 ./your_binary its not working as it takes this file from /lib/libc.so.6 . I want it at that above location – Jatin Bodarya Jan 17 '13 at 09:12
  • Ok, I got it backwards. I edited the answer to reflect the shared object that you want. – Alberto Miranda Jan 17 '13 at 09:20
  • libc.so.6 => /lib/i386-linux-gnu/libc.so.6 its working now /lib/ld-linux.so.2 file shows same GLIBC error.. can I use multiple path ? or how can I make other /root partition with different name and can run this binary from there but without using "chroot" – Jatin Bodarya Jan 17 '13 at 09:42
  • Yes, you can add as many search paths to LD_LIBRARY_PATH as you need, as long as you separate them with `:`, eg: `LD_LIBRARY_PATH=/first/path:/second/path`. I don't know any way to do something like `chroot` without using `chroot`, sorry. – Alberto Miranda Jan 17 '13 at 09:48
  • LD_LIBRARY_PATH=/var/xxx/lib/:/lib/i386-linux-gnu/ ldd /usr/local/sbin/my_binary /bin/sh: /lib/ld-linux.so.2: version `GLIBC_2.3' not found (required by /lib/i386-linux-gnu/libc.so.6) /bin/sh: /lib/ld-linux.so.2: version `GLIBC_PRIVATE' not found (required by /lib/i386-linux-gnu/libc.so.6) in /var/xxx newer ld-linux.so.2 is avilable – Jatin Bodarya Jan 17 '13 at 09:54
  • It seems that you have a lot of problems with symbol versioning. The binary you're trying to run was compiled in that old machine? Or are you trying to 'port' a binary compiled in another architecture. If it's the latter, you'd be better off recompiling the program in your target machine, with the appropriate compiler toolchain. – Alberto Miranda Jan 17 '13 at 10:10
  • well that is the problem there is no compiler in my target machine So I suppose to compile it on new machine and make it executable with that older one – Jatin Bodarya Jan 17 '13 at 10:12
  • If you don't have a compiler maybe one of these solutions (http://stackoverflow.com/a/8658468/1984421) will work for you. Good luck! – Alberto Miranda Jan 17 '13 at 10:16
  • okk... Can I download whole GLIBC-2.4 from some where put it into one directory and with LD_LIBRARY_PATH execute my binary ? – Jatin Bodarya Jan 17 '13 at 10:21
  • Most probably not. If you find a binary distribution of GLIBC-2.4, it's not guaranteed to work on your machine unless the environment is exactly the same. If you download a source distribution you will have to compile the library, but you said that you don't have a compiler in your old machine so that's a no no. – Alberto Miranda Jan 17 '13 at 10:30
0

If you want to run 32-bit executables on a 64-bit machine, you'll need to install the 32 bit versions. On Fedora or other systems with yum run:

yum install glibc.i686

(note the .i686 suffix, it asks specifically for the 32 bit versions) and try again. The ldd(1) command should help identifying the needed libraries, and yum should be smart enough to find them by the name it gives.

vonbrand
  • 11,412
  • 8
  • 32
  • 52