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.
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
> 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.
> devel mailing list