I’m having an issue with the MPI version of application and the dynamic relocation of symbols from plugin shared libraries. 


There are duplicate symbols in both the main executable (Engine) and a shared library that opened at runtime using dlopen (Plugin).  The plugin is opened with the command dlopen(pFilepath, RTLD_LAZY | RTLD_LOCAL).  When I run the entry point function that I get using dlsym, there is a segmentation violation that occurs during the execution of that function.  The mpirun outputs the backtrace of the segfault, and in it I can see that execution goes from the engine to the plugin and back to the engine.  The plugin is statically linked to a class library that is also statically linked to the engine (but a different version) and contains a couple of files found in the engine (again a different version).  The plugin should be completely self sufficient, meaning it has everything it needs to function independently of the engine, and should never need to have symbols dynamically linked to the engine. 


When I run the single (non-MPI) version of the application, it runs fine (apparently without plugin symbol relocation).  When I run the MPI version, I get the segfault.  The code that handles plugins is the same in both versions, and doesn’t rely on any MPI functionality.


Is there some way to change how the MPI runtime uses the executable so it doesn’t export the symbols?  Or any way to prevent the dynamical symbol relocation when loading the shared library?  Or linker flags that I could use with plugin shared library so it does list its internal symbols?


I have a Stack Overflow question on this here:






Matt Cupp
Battelle Memorial Institute
Statistics and Information Analysis