Not exactly - see below
On Oct 6, 2008, at 11:56 AM, Jeff Squyres wrote:
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.
Not quite. In this case, we specifically did include --enable-
visibility so that it would be there for those compilers that support
it. We didn't realize that visibility was going to be included for a
debug build even if we -didn't- request it.
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.
Yes, in this case it is a bug. Shiqing is on holiday, but already
contacted me about it. We'll deal with it upon his return.
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
_______________________________________________
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel
