Look like VT do not correctly compute dependencies. A static build
will fails if libz.a is not installed on the system.
/usr/bin/ld: cannot find -lz
collect2: ld returned 1 exit status
make[5]: *** [vtfilter] Error 1
george.
On Jan 28, 2008, at 12:37 PM, Matthias Jurenz wrote:
Hello,
thi
DSO build also fail.
../../../../../../trunk/ompi/contrib/vt/vt/vtlib/vt_comp_gnu.c:312:5:
warning: "VT_BFD" is not defined
../../../../../../trunk/ompi/contrib/vt/vt/vtlib/vt_comp_gnu.c:312:5:
warning: "VT_BFD" is not defined
/usr/bin/ld: cannot find -lz
collect2: ld returned 1 exit status
On Di, 2008-01-29 at 02:53 -0500, Aurélien Bouteiller wrote:
> DSO build also fail.
>
> ../../../../../../trunk/ompi/contrib/vt/vt/vtlib/vt_comp_gnu.c:312:5:
> warning: "VT_BFD" is not defined
> ../../../../../../trunk/ompi/contrib/vt/vt/vtlib/vt_comp_gnu.c:312:5:
> warning: "VT_BFD" is not d
On Tuesday 29 January 2008, George Bosilca wrote:
> Look like VT do not correctly compute dependencies. A static build
> will fails if libz.a is not installed on the system.
>
> /usr/bin/ld: cannot find -lz
> collect2: ld returned 1 exit status
> make[5]: *** [vtfilter] Error 1
>
>george.
>
th
We have run into another issue with the vt integration. Configuring with
'--disable-mpi-io' results in:
vt_mpiwrap.c:3565: error: `fh' undeclared (first use in this function)
vt_mpiwrap.c:3565: error: `buf' undeclared (first use in this function)
vt_mpiwrap.c:3565: error: `count' undeclared (fir
Good catch. It seems to be an issue with component priority.
I'll dig into it...
On Jan 28, 2008, at 6:49 PM, Josh Hursey wrote:
I noticed that when running configure on the nightly snapshot tarball
the following errors (warnings really, since it didn't stop
configure) were produced. These s
Thanks :)
For anyone interested Jeff filed a ticket on this bug here:
https://svn.open-mpi.org/trac/ompi/ticket/1205
-- Josh
On Jan 29, 2008, at 8:16 AM, Jeff Squyres wrote:
Good catch. It seems to be an issue with component priority.
I'll dig into it...
On Jan 28, 2008, at 6:49 PM, Josh
I got a bunch of compiler warnings and errors with VT on the PGI
compiler last night -- my mail client won't paste it in nicely. :-(
See these MTT reports for details:
- On Absoft systems:
http://www.open-mpi.org/mtt/index.php?do_redir=516
- On Cisco systems:
With PGI compilers:
htt
Jeff Squyres wrote:
I got a bunch of compiler warnings and errors with VT on the PGI
compiler last night -- my mail client won't paste it in nicely. :-(
See these MTT reports for details:
- On Absoft systems:
http://www.open-mpi.org/mtt/index.php?do_redir=516
- On Cisco systems:
With P
Hi Tim,
the configure script of the vt-integration don't check whether MPI I/O
is disabled, so
the VT's MPI_File_* wrapper functions will be built. A quick solution
for this problem should be
to add the option "--with-contrib-vt-flags=--without-mpi-io" to the
configure script.
I'm working on a b
I just wanted to give a public "thank you!" to the Absoft Corporation
(the fortran compiler company): Absoft is the first organization who
is not a core member of the Open MPI project to run automated Open MPI
regression testing and submit the results back to our centralized
testing databas
On Jan 29, 2008, at 9:24 AM, Tim Prins wrote:
- On Cisco systems:
With PGI compilers:
http://www.open-mpi.org/mtt/index.php?do_redir=517
With GNU compilers:
http://www.open-mpi.org/mtt/index.php?do_redir=518
Note that this last link points to the IU failures when configuring
wi
Hello,
all three VT related errors which MTT reported should be fixed now.
516:
The fix from George Bosilca at this morning should work on MacOS PPC.
Thanks!
517:
The compile error occurred due to a missing header include.
Futhermore, the compiler warnings should be also fixed.
518:
I have add
On Jan 29, 2008, at 12:13 PM, Matthias Jurenz wrote:
518:
I have added a check whether MPI I/O is available and add the
corresponding VT's
configure option to enable/disable MPI I/O support. Therefor I used
the variable
"define_mpi_io" from 'ompi/mca/io/configure.m4'. Is that o.k. or
shoul
Are the group operations in ORTE (I assume this is what the grpcomm
component does) available to subsets of a job, or do all procs in the
orte_jobid_t need to invoke this ?
Thanks,
Rich
Depends upon which one you are using. For example, allgather operates across
the entire job, so all procs in that jobid have to invoke it. On the other
hand, allgather_list only operates across the procs specified in the list,
so only they need to invoke it.
Xcast sends a message to all procs in t
Sounds like xcast will do what I need.
If I don't pull data on all the procs, only the ones calling the recv, will
I basically create a memory leak ?
Thanks,
Rich
On 1/29/08 2:27 PM, "Ralph H Castain" wrote:
> Depends upon which one you are using. For example, allgather operates across
> the
At the moment I do not plan on joining the crcpw and v_protocol.
However those two components may currently work just fine together.
They are both designed to wrap around whatever the 'selected' PML
happens to be. If you tried to do this, I would expect the PML call
stack to look something
Yes and no. It will consume memory as the message will enter the proc's OOB
and just sit there. However, it will be released when the proc finalizes the
RTE.
If that would be a problem, it would be pretty easy to add a directive to
"delete this message if a recv isn't already waiting for it".
Alt
I just agree with Josh. We though about it a bit, and nothing should
prevent to use both.
Aurelien
Le 29 janv. 08 à 15:01, Josh Hursey a écrit :
At the moment I do not plan on joining the crcpw and v_protocol.
However those two components may currently work just fine together.
They are both
The previous code was correct. Each IP address correspond to a
specific endpoint, and therefore to a specific BTL. This enable us to
have multiple TCP BTL at the same time, and allow the OB1 PML to
stripe the data over all of them.
Unfortunately, your commit disable the multi-rail over TCP.
21 matches
Mail list logo
