Skip to content

Add extra_rpath paths into rpath commands for openmpi wrappers.#8687

Merged
scheibelp merged 1 commit intospack:developfrom
jrood-nrel:openmpi_rpaths
Jul 30, 2018
Merged

Add extra_rpath paths into rpath commands for openmpi wrappers.#8687
scheibelp merged 1 commit intospack:developfrom
jrood-nrel:openmpi_rpaths

Conversation

@jrood-nrel
Copy link
Copy Markdown
Member

This is my proposed solution for #8670 . It solved my problem where I use a GCC not installed in /usr for example, with extra_rpaths set to point to that GCC's libraries. Then when I build OpenMPI > 1.10.x using fabrics=verbs, which uses --with-verbs during OpenMPI configure, it finds the infiniband drivers in /usr/lib64 so then it adds -Wl,-rpath -Wl,/usr/lib64 to the OpenMPI wrappers. So then when I use the OpenMPI module to build other random software outside of Spack, the wrappers rpath /usr/lib64 into the executable which then has GLIBC, GLIBCXX runtime errors due to it picking up libraries in /usr/lib64 which is the system GCC, rather than my GCC I'm actually using which is installed elsewhere.

Therefore this pull request adds in the directories from compilers.yaml extra_rpaths into the OpenMPI wrappers using rpath as well. After testing it, it solves the problem I was having with OpenMPI 3.1.0 for example when creating executables with its wrappers.

@jrood-nrel
Copy link
Copy Markdown
Member Author

@alalazo Does this seem like a reasonable thing to do? I feel like it is a necessity, otherwise I am not able to use OpenMPI on machines exhibiting this behavior and the extra_rpaths exist for this exact reason so shouldn't they propagate to the MPI wrappers as well?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants