Re: [OMPI devel] More VT warnings

2008-02-01 Thread Ralf Wildenhues
* Tim Prins wrote on Fri, Feb 01, 2008 at 04:09:31PM CET: > > Note that this indicates that the file vt_metric_papi.c is being > compiled *3* times. I am not using a parallel make here. Any ideas why > it is compiling 3 times? The file is listed as source file to four different libraries, and p

Re: [OMPI devel] [OMPI svn] svn:open-mpi r17307

2008-02-01 Thread Tim Prins
Adrian, For the most part this seems to work for me. But there are a few issues. I'm not sure which are introduced by this patch, and whether some may be expected behavior. But for completeness I will point them all out. First, let me explain I am working on a machine with 3 tcp interfaces, l

Re: [OMPI devel] VT in trunk + how to disable

2008-02-01 Thread Jeff Squyres
I think my position is about the same as Terry's. I also think we have a precedent for building everything that is possible and letting the user choose at run-time what they want to do. My $0.02 is that it's easier to tell random users (and customers!) "yes, OMPI should have built that for

Re: [OMPI devel] VT in trunk + how to disable

2008-02-01 Thread Terry Dontje
Josh Hursey wrote: Should the default be to *disable* vampirtrace? I mention this since, I assume, most people do not depend on this tool for every Open MPI install. Meaning that Open MPI does not require this integration for correct MPI functionality unlike something like ROMIO [example o

[OMPI devel] More VT warnings

2008-02-01 Thread Tim Prins
With a fresh checkout, I get the following warnings: vt_metric_papi.c:72: warning: no previous prototype for ‘vt_metric_error’ vt_metric_papi.c:86: warning: no previous prototype for ‘vt_metric_warning’ vt_metric_papi.c:100: warning: function declaration isn’t a prototype vt_metric_papi.c: In fun

Re: [OMPI devel] 32 bit openib btl warnings

2008-02-01 Thread Jeff Squyres
Cool; I missed that one -- thanks. On Feb 1, 2008, at 9:25 AM, Tim Prins wrote: These were fixed by Gleb yesterday in https://svn.open-mpi.org/trac/ompi/changeset/17346 Tim Jeff Squyres wrote: I noticed these in IBM's MTT runs on the rhc branch last night: btl_openib_frag.c: In function 'o

Re: [OMPI devel] 32 bit openib btl warnings

2008-02-01 Thread Tim Prins
These were fixed by Gleb yesterday in https://svn.open-mpi.org/trac/ompi/changeset/17346 Tim Jeff Squyres wrote: I noticed these in IBM's MTT runs on the rhc branch last night: btl_openib_frag.c: In function 'out_constructor': btl_openib_frag.c:74: warning: cast from pointer to integer of

[OMPI devel] 32 bit openib btl warnings

2008-02-01 Thread Jeff Squyres
I noticed these in IBM's MTT runs on the rhc branch last night: btl_openib_frag.c: In function 'out_constructor': btl_openib_frag.c:74: warning: cast from pointer to integer of different size btl_openib_frag.c: In function 'recv_constructor': btl_openib_frag.c:120: warning: cast from pointer t

Re: [OMPI devel] vt compiler warnings and errors

2008-02-01 Thread Jeff Squyres
On Feb 1, 2008, at 5:35 AM, Ralf Wildenhues wrote: These files do not belong in SVN, they are generated by aclocal: ompi/contrib/vt/vt/extlib/otf/aclocal.m4 ompi/contrib/vt/vt/aclocal.m4 I think both of these have their own configure scripts, meaning that they were autoconfed/automaked/wh

Re: [OMPI devel] VT in trunk + how to disable

2008-02-01 Thread Josh Hursey
Should the default be to *disable* vampirtrace? I mention this since, I assume, most people do not depend on this tool for every Open MPI install. Meaning that Open MPI does not require this integration for correct MPI functionality unlike something like ROMIO [example of opt-out functional

Re: [OMPI devel] vt compiler warnings and errors

2008-02-01 Thread Ralf Wildenhues
* Jeff Squyres wrote on Thu, Jan 31, 2008 at 07:10:36PM CET: > Ah -- I didn't notice this before -- do you have a configure script > committed to SVN? If so, this could be the problem. > > On Do, 2008-01-31 at 08:09 -0500, Tim Prins wrote: [...] > >> [tprins@sif test]$ make clean > >> > >> Mak

Re: [OMPI devel] vt compiler warnings and errors

2008-02-01 Thread Andreas Knüpfer
Hi everybody, now this is an interesting effect. After a fresh checkout all files have the actual time, haven't they? Is the timestamp explicitly saved somewhere? Could it be, that this is newer than Tim's local time yesterday? Maybe the system time is not set to UTC or something like this? I