Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Development mailing list

Subject: Re: [OMPI devel] Should visibility and memchecker abort configure?
From: Ralph Castain (rhc_at_[hidden])
Date: 2008-10-03 09:26:21

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
>> devel_at_[hidden]
> _______________________________________________
> devel mailing list
> devel_at_[hidden]