On Oct 3, 2008, at 9:26 AM, Ralph Castain wrote:
> However, what about memchecker? Per my earlier note that crossed
> this one, is the current behavior a "bug"?
As I said if one request the memchecker and we cannot satisfy it, then
we should exit with a big error message that clearly state that we are
unable to find any (or some specific) version of the valgrind libraries.
The behavior related to memchecker you described in your second email
seems like a deviation from this, so from my perspective it should be
considered as 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
>> 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
>> 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.
>> 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
>>> If this would be acceptable, I am happy to help with or implement
>>> the changes. It would be greatly appreciated.
>>> devel mailing list
>> devel mailing list
> devel mailing list