Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Development mailing list

Subject: Re: [OMPI devel] Should visibility and memchecker abort configure?
From: Jeff Squyres (jsquyres_at_[hidden])
Date: 2008-10-06 13:56:10

I think the real issue here is that --enable-debug (or the presence of
the .svn or .hg directories) *implies* several other options, such as
--enable-visibility and --enable-memchecker.

As I understand it: the user has *not* specifically asked for --enable-
visibility, but is getting a failure if it can't be delivered because
--enable-debug was specified. Is that right? If so, that's downright
weird -- because I configure/compile with the PGI compilers with --
enable-debug and simply get a build that does not include visibility
(i.e., "ompi_info | grep visibil" results in "Symbol visibility
support: no") -- the configure/build does not abort.

Additionally, I agree that if the memchecker/valgrind component cannot
deliver what it should, it should disable itself silently/without
error *unless* the valgrind component was specifically requested
(which, in this case, it sounds like it was not). So if we're not
doing that, it's a bug.

On Oct 5, 2008, at 5:15 AM, Ralf Wildenhues wrote:

> Hello,
> if you allow me my 2 cents:
> At configure time, it is possible to distinguish between several
> different user inputs:
> - the user typed --enable-foo,
> - the user typed --disable-foo or --enable-foo=no,
> - the user typed --enable-foo=ARG (ARG is available for further
> inspection),
> - the user used none of the above.
> IIUC you have already sorted out the visibility issue by using the
> last,
> and the memchecker issue is about having an incompatible version
> installed. One typical semantics would be to not try to use the
> feature
> at all if --disable-foo was explicitly passed.
> Hope that helps.
> Cheers,
> Ralf
> _______________________________________________
> devel mailing list
> devel_at_[hidden]

Jeff Squyres
Cisco Systems