On Wed, 13 Sep 2017 20:13:54 +0430 Mahmood Naderan <mahmood...@gmail.com> wrote: ... > `/usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../lib64/libc.a(strcmp.o)' > can not be used when making an executable; recompile with -fPIE and > relink with -pie collect2: ld returned 1 exit status > > > With such an error, I thought it is better to forget static linking! > (as it is related to libc) and work with the shared libs and > LD_LIBRARY_PATH
First, I think giving up on static linking is the right choice. If the main thing you were after was the convenience of a binary that will run without the need to setup LD_LIBRARY_PATH correctly you should have a look at passing -rpath to the linker. In short, "mpicc -Wl,-rpath=/my/lib/path helloworld.c -o hello", will compile a dynamic binary "hello" with built in search path to "/my/lib/path". With OpenMPI this will be added as a "runpath" due to how the wrappers are designed. Both rpath and runpath works for finding "/my/lib/path" wihtout LD_LIBRARY_PATH but the difference is in priority. rpath is higher priority than LD_LIBRARY_PATH etc. and runpath is lower. You can check your rpath or runpath in a binary using the command chrpath (package on rhel/centos/... is chrpath): $ chrpath hello hello: RUNPATH=/my/lib/path If what you really wanted is the rpath behavior (winning over any LD_LIBRARY_PATH in the environment etc.) then you need to modify the openmpi wrappers (rebuild openmpi) such that it does NOT pass "--enable-new-dtags" to the linker. /Peter _______________________________________________ users mailing list users@lists.open-mpi.org https://lists.open-mpi.org/mailman/listinfo/users
