2

I am having a peculiar problem. I have a shared library 'my_tracker.so' that I built using gcc-4.2. This shared library now has a dependency on libgcc_s.so.1 (GCC 4.2). I did 'ldd my_tracker.so' and it picked up libgcc_s.so.1 from /lib64.

I am running the

'LD_PRELOAD=my_tracker.so LD_LIBRARY_PATH=[vnc_install]/lib/vnclibs:$LD_LIBRARY_PATH vncserver'

inside my script. I want to make sure the vncserver gets its libgcc_so.1 (GCC 3.2.3) from the [vnc_install]/lib/vnclibs/ and hence put it in front of LD_LIBRARY_PATH.

However,after executing my script, it looks like the vncserver is picking up libgcc_s.so.1 (GCC 4.2) from /lib64.

Does the loading of my pre-loaded shared library 'my_tracker.so' prepend the LD_LIBRARY_PATH with where libgcc_s.so.1 (GCC 4.2) was found?

If so, how can I fix this issue?

Regards John

Michael Dillon
  • 31,973
  • 6
  • 70
  • 106
johnm
  • 21
  • 2
  • Why are you trying to use an older version of libgcc_s.so.1? What if libc or something requires a newer version... – bdonlan Jul 08 '11 at 18:26
  • 1
    No the vncserver binary I am using links to an older version of libgcc_s.so.1. I don't have the source of vncserver to recompile it. But on a broader note, how can you run binaries compiled with diff versions of the gcc compiler (and links with diff versions of libgcc_s.so.1) on a generic Linux system ? – johnm Jul 08 '11 at 20:22

1 Answers1

0

The solution to this is to get patchelf and use it to patch your binary, and any copied libraries, to use RPATH. Then you can ignore LD_LIBRARY_PATH entirely. And if you need a different ld-linux.so to load your binary, patchelf can fixup the binary to find that as well.

Michael Dillon
  • 31,973
  • 6
  • 70
  • 106
  • Thank you for this suggestion. I will look into this. However, I don't think this is a general solution since I won't be able to run patchelf on every binary that I want to run with my pre-loaded library. – johnm Jul 15 '11 at 17:48