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
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel
--
Jeff Squyres
Cisco Systems
