FWIW: It’s Slurm’s pmi-1 library that isn’t linked correctly against its dependencies (the pmi-2 one is correct). Moe is aware of the problem and fixing it on their side. This won’t help existing installations until they upgrade, but I tend to agree with Jeff about not fixing other people’s problems.
> On Dec 1, 2014, at 1:55 PM, Jeff Squyres (jsquyres) <jsquy...@cisco.com> > wrote: > > 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/ > > _______________________________________________ > devel mailing list > de...@open-mpi.org > Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel > Link to this post: > http://www.open-mpi.org/community/lists/devel/2014/12/16381.php
