On Wed, Feb 25, 2015 at 9:56 AM, Jeff Squyres (jsquyres) <jsquy...@cisco.com > wrote:
> On Feb 25, 2015, at 11:51 AM, Dave Goodell (dgoodell) <dgood...@cisco.com> > wrote: > > > >> This is a good question: what should we do here? > >> > >> 1. Abort the configure (e.g., insist that the user install libltdl or > --disable-dlopen) > > > > I'd do this. A clear message should make this no big deal for users, > and in some cases it improves our odds of getting a (much welcome) report > about some buggy dl component (or build system) logic. > > I did that and just shipped a tarball to get Hargroved. > Tests have been dispatched... I will report complete results later today. The first of the BSD results should be in soon, and I'll plan to report go/nogo. > However, I'm a bit uneasy about it -- this is different than most other > OMPI configure CLI options. Most others are "if unspecified, try it and > use it if we can, and skip it if we can't". This would be a departure from > that. :-\ Assuming that the new tarball finds dlopen() support in libc on the BSDs then I am not going to encounter the new behavior unless I manually disable (something like "--enable-mca-no-build=dl-dlopen", right?). To be honest, any platform that does reach this point is going to be rare (in the absence of the bugs that Dave refers to). So, this "departure" seems to be pretty minor (IMHO). It really comes down to: "Sorry, but we can't fix the situation without your help - you must chose to either (1) install libltdl for dynamically linked components or (2) --disable-dlopen for statically linked components". -Paul -- Paul H. Hargrove phhargr...@lbl.gov Computer Languages & Systems Software (CLaSS) Group Computer Science Department Tel: +1-510-495-2352 Lawrence Berkeley National Laboratory Fax: +1-510-486-6900
