Open MPI logo

Open MPI User's Mailing List Archives

  |   Home   |   Support   |   FAQ   |  

This web mail archive is frozen.

This page is part of a frozen web archive of this mailing list.

You can still navigate around this archive, but know that no new mails have been added to it since July of 2016.

Click here to be taken to the new web archives of this list; it includes all the mails that are in this frozen archive plus all new mails that have been sent to the list since it was migrated to the new archives.

Subject: Re: [OMPI users] Dynamic Symbol Relocation in Plugin Shared Library
From: Cupp, Matthew R (cuppm_at_[hidden])
Date: 2009-12-04 11:24:03

We are using 1.3.3. I found the linker flag -Bsymbolic, and applying it to the plugin appears to have fixed the issue. The problem is a result of not properly structuring the plugin's code and having duplicate symbol names, the behavior of Open MPI just brought them to the light.

Thanks for your help,
Matt Cupp
Battelle Memorial Institute
Statistics and Information Analysis

-----Original Message-----
From: users-bounces_at_[hidden] [mailto:users-bounces_at_[hidden]] On Behalf Of Jeff Squyres
Sent: Thursday, December 03, 2009 5:56 PM
To: Open MPI Users
Subject: Re: [OMPI users] Dynamic Symbol Relocation in Plugin Shared Library

What version of Open MPI are you using? We just made a minor-but-potentially-important change to how we handle our dlopen code in 1.3.4.

Additionally, you might try configuring Open MPI with the --disable-dlopen configure switch. This switch does two things:

1. Slurps all of Open MPI's plugins up into normal libraries (e.g., or libmpi.a)
2. Disables / compiles out all of Open MPI's dlopen (and related) code

If 1.3.4 doesn't fix your problem, then --disable-dlopen should.

On Dec 3, 2009, at 2:56 PM, Cupp, Matthew R wrote:

> Hi,
> 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:
> Thanks!
> Matt
> ______________________________
> Matt Cupp
> Battelle Memorial Institute
> Statistics and Information Analysis
> _______________________________________________
> users mailing list
> users_at_[hidden]

Jeff Squyres
users mailing list