Ah! I was unaware of that behavior for visibility. Thanks for
clarifying - that's a behavior I can live with.
However, what about memchecker? Per my earlier note that crossed this
one, is the current behavior a "bug"?
On Oct 3, 2008, at 7:18 AM, George Bosilca wrote:
Ralph in order to have the behavior you describe for the visibility
feature just don't specify --enable-visibility. This will enable it
if the feature is supported and disable (plus a small warning) if not.
We decided a while ago that 1) we should have a consistent behavior
for similar scenarios and 2) if the user explicitly request
something and we are unable to satisfy the request we exit with a
big error message. This make perfectly sense as we all know that the
output (with the exit) will be utterly ignored by 99.9% of people.
If some of the --enable options do not abort the configuration when
their condition is not satisfied, then this is the bug and we should
correct it asap.
george.
On Oct 2, 2008, at 6:04 PM, Ralph Castain wrote:
Hi folks
I make heavy use of platform files to provide OMPI support for the
three NNSA labs. This means supporting multiple compilers, several
different hardware and software configs, debug vs optimized, etc.
Recently, I have encountered a problem that is making life
difficult. The problem revolves around two configure options that
apply to debug builds:
1. --enable-visibility. Frustrating as it may be, some compilers
just don't support visibility - and others only support it for
versions above a specific level. Currently, this option will abort
the configure procedure if the compiler does not support visibility.
2. --enable-memchecker. This framework has a component that
requires valgrind 3.2 or above. Unfortunately, if a valgrind
meeting that criteria is not found, this option will also abort the
configure procedure.
Is it truly -necessary- for these options to abort configure in
these conditions? Would it be acceptable for:
* visibility just to print a big warning, surrounded by asterisks,
that the selected compiler does not support visibility - but allow
the build to continue?
* memchecker to also print a big warning, surrounded by asterisks,
explaining the valgrind requirement and turn "off" the build of the
memchecker/valgrind component - but allow the build to continue? It
would seem to me that we would certainly want this for the future
anyway as additional memchecker components are supported.
If this would be acceptable, I am happy to help with or implement
the changes. It would be greatly appreciated.
Thanks
Ralph
_______________________________________________
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel
_______________________________________________
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel
