On Dec 1, 2014, at 4:07 PM, Howard Pritchard <hpprit...@gmail.com> wrote:
> There has been some discussion of end case situations with use of dlopen > in the ompi mca framework that can lead to unresolved symbols when > subsequent shared libraries are dlopen'd that might needs symbols from > a library that had been opened previously. Yes these libraries should be > doing something like a second dlopen of the lib they are dependent on, > but that's a different story involving other software projects outside of > ompi. Those other projects should be fixed. OMPI should not be the compromise location where we compensate for other projects that do not obey proper linking semantics. Can you cite some specific examples? > The default with the mca framework dlopen'ing of component libraries > is not to use RTLD_GLOBAL, and there does not currently appear to be a way > to change this behavior at runtime. > > Is there a reason for avoiding use of RTLD_GLOBAL in libltdl's use of dlopen? Yes. There's at least two reasons that I can think of off the top of my head: 1. It's the Right Thing to do. I.e., we shouldn't pollute the general namespace with symbols from dependent libraries. 2. We've had specific user requests to not pollute the general namespace. One specific case was because we use an embedded copy of libevent, and another MPI-based program also uses libevent. If we didn't keep libevent in a private namespace, Bad Things (i.e., symbol clashes) would occur. > Would it be okay to add RTLD_GLOBAL to the default module_flags used > in the vm_open - modulo detection of the definition of RTLD_GLOBAL at > compile time. No. > Perhaps adding a way with an env. or config option to not > enable RTLD_GLOBAL by default? This just seems like a bad path to go down. -- Jeff Squyres jsquy...@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
