Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |  

This web mail archive is frozen.

This page is part of a frozen web archive of this mailing list.

You can still navigate around this archive, but know that no new mails have been added to it since July of 2016.

Click here to be taken to the new web archives of this list; it includes all the mails that are in this frozen archive plus all new mails that have been sent to the list since it was migrated to the new archives.

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

On Oct 3, 2008, at 1:59 AM, Aurélien Bouteiller wrote:

> Hi Ralph,
> 1. No. Having visibility turned off without knowing it is the best
> way for us to commit bugs in the trunk without noticing, I mean
> before somebody else get the leg caught in the "not-compiling-trunk
> trap". I had more of my share of responsibility for that kind of
> problems in the past, that exactly rooted in visibility issues. I
> must say that it is painful enough that some compilers will just
> silently ignore visibility settings without adding the configure to
> the chain of guys who just do whatever they want regardless of the
> requested flags. If I can't have visibility, I want to know.
> Especially in debug mode.

Not sure you understood my proposal. I didn't say you wouldn't know
that visibility was not supported - in fact, I suggested a large
blaring warning. I just don't believe it should cause the entire build
to abort. The fact is that compilers such as PGI simply don't support
it, so whether we believe it is important or not, you are not going to
get visibility warnings. Once you build, you'll never again see a
warning of that fact, so it isn't clear to me what we accomplish by
aborting a configure as opposed to blasting out a warning.

> 2. If Valgrind is not available and this feature requires valgrind,
> it is reasonable to disable it. Anyway, this would not lead to
> include silent bugs in the trunk if it gets disabled "silently".
> (are you sure though ? I used to enable this on my mac, where there
> is of course no valid valgrind installed, and it compiled just fine).

I verified this. The problem is that there is a valgrind installed -
however, it doesn't meet the release criterion. In the case of the
Mac, there is no valgrind at all - the configure script seems happy
with that scenario.

I suspect we could consider this portion of the problem a "bug"?

> Aurelien
> Le 2 oct. 08 à 18:04, Ralph Castain a écrit :
>> 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]