CODEWITHSUNDEEP
dynamic-linkinglibcdynamic-librarympichrpath
bdd
bdd

Reputation: 63

Executable not linking to the my desired dynamic library

I have built and installed mpich from source (mpich-3.4.1.tar.gz), using the steps given in 'https://www.mpich.org/static/downloads/3.4.1/mpich-3.4.1-README.txt'. I want the resultant executables to be dynamically linked to libraries specified in the path '/home/myname/mylibs'. So, before calling ./configure, I have set my LD_LIBRARY_PATH as: setenv LD_LIBRARY_PATH /home/myname/mylibs:$LD_LIBRARY_PATH

Inside the directory '/home/myname/mylibs' I have soft linked 'libc.so.6' and 'libstdc++.so.6' to my desired libraries, as I do not want the resultant executables to link to dynamic libraries from path /lib64/. I was able to build and install mpich in my machine. However, when I call 'ldd' on one of the executables (hydra_pmi_proxy) that were generated, I see the following:

$ ldd /home/myname/mpich-3.4.1_install/bin/hydra_pmi_proxy

libc.so.6 => /lib64/libc.so.6 (0x00007f32f9eef000)

libstdc++.so.6 => /home/myname/mylibs/libstdc++.so.6 (0x00007f32f9542000)

The rpath seems to be set to my desired path '/home/myname/mylibs' as shown below:

$ readelf -d /home/myname/mpich-3.4.1_install/bin/hydra_pmi_proxy | egrep "RPATH|RUNPATH"

0x000000000000000f (RPATH) Library rpath: [/home/myname/mylibs]

As shown above, libstdc++.so.6 is pointing to my desired library, but libc.so.6 is still pointing to /lib64/libc.so.6. I want libc.so.6 to point to /home/myname/mylibs/libc.so.6 Is there anything I can do to make this possible?

I do not want my exe to be dynamically linked to libraries in /lib64/ because when I launch my MPI program on multiple machines it seems 'hydra_pmi_proxy' is trying to dynamically link to the /lib64/libc.so.6 of the machine on which a certain process is running. (Most likely, it spawns a child process on the new machine which in turn dynamically links to /lib64/libc.so.6 of that machine). I have seen that I am getting an error when one of the mpi processes tries to run on any machine in which /lib64/libc.so.6 is pointing to an older version. The error is: /home/myname/mpich-3.4.1_install/bin/hydra_pmi_proxy: /lib64/libc.so.6: version `GLIBC_2.17' not found (required by /home/myname/mpich-3.4.1_install/bin/hydra_pmi_proxy). When I login to this machine, in which it is failing, and do strings /lib64/libc.so.6 | grep GLIBC_2, I do not see GLIBC_2.17 listed. Whereas, on all other machines, on which the mpi processes are running successfully, I see GLIBC_2.17 listed on running 'strings'. So, my intention is to make all executables to dynamically link to only libraries at "/home/myname/mylibs/". Is this the right way?

Upvotes: 0

Views: 638

Answers (1)

Employed Russian
Employed Russian

Reputation: 213799

I do not want the resultant executables to link to dynamic libraries from path /lib64/

libc.so.6 is a special case. See this answer to understand why.

If you really want to isolate your binaries from libraries in /lib64/..., you must:

  1. configure build and install into /home/myname/mylibs/ a new version of GLIBC (symlinking isn't sufficient) and
  2. set your --dynamic-linker and --rpath to point into mylibs.

That said, you didn't explain why you don't want to link libraries from /lib64. http://xyproblem.info might be relevant here.

Upvotes: 0

Related Questions