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:
> 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
> - the user used none of the above.
> IIUC you have already sorted out the visibility issue by using the
> and the memchecker issue is about having an incompatible version
> installed. One typical semantics would be to not try to use the
> at all if --disable-foo was explicitly passed.
> Hope that helps.
> devel mailing list