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

[George Bosilca]

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. Please  
undo it.


  Thanks,
george.

On Jan 29, 2008, at 10:55 AM, a...@osl.iu.edu wrote:


Author: adi
Date: 2008-01-29 10:55:56 EST (Tue, 29 Jan 2008)
New Revision: 17307
URL: https://svn.open-mpi.org/trac/ompi/changeset/17307

Log:
accept incoming connections from hosts with multiple addresses.

We loop over all peer addresses and accept when one of them matches.
Note that this might break functionality: mca_btl_tcp_proc_insert now
always inserts the same endpoint. (is the lack of endpoints the  
problem?

should there be one for every remote address?)

Re #1206


Text files modified:
  trunk/ompi/mca/btl/tcp/btl_tcp_proc.c |12 ++--
  1 files changed, 6 insertions(+), 6 deletions(-)

Modified: trunk/ompi/mca/btl/tcp/btl_tcp_proc.c
= 
= 
= 
= 
= 
= 
= 
= 
==

--- trunk/ompi/mca/btl/tcp/btl_tcp_proc.c   (original)
+++ trunk/ompi/mca/btl/tcp/btl_tcp_proc.c	2008-01-29 10:55:56 EST  
(Tue, 29 Jan 2008)

@@ -327,16 +327,16 @@
{
size_t i;
OPAL_THREAD_LOCK(_proc->proc_lock);
-for( i = 0; i < btl_proc->proc_endpoint_count; i++ ) {
-mca_btl_base_endpoint_t* btl_endpoint = btl_proc- 
>proc_endpoints[i];

+for( i = 0; i < btl_proc->proc_addr_count; i++ ) {
+mca_btl_tcp_addr_t*  exported_address = btl_proc- 
>proc_addrs + i;
/* Check all conditions before going to try to accept the  
connection. */
-if( btl_endpoint->endpoint_addr->addr_family != addr- 
>sa_family ) {

+if( exported_address->addr_family != addr->sa_family ) {
continue;
}

switch (addr->sa_family) {
case AF_INET:
-if( memcmp( _endpoint->endpoint_addr->addr_inet,
+if( memcmp( _address->addr_inet,
&(((struct sockaddr_in*)addr)->sin_addr),
sizeof(struct in_addr) ) ) {
continue;
@@ -344,7 +344,7 @@
break;
#if OPAL_WANT_IPV6
case AF_INET6:
-if( memcmp( _endpoint->endpoint_addr->addr_inet,
+if( memcmp( _address->addr_inet,
&(((struct sockaddr_in6*)addr)->sin6_addr),
sizeof(struct in6_addr) ) ) {
continue;
@@ -355,7 +355,7 @@
;
}

-if(mca_btl_tcp_endpoint_accept(btl_endpoint, addr, sd)) {
+if(mca_btl_tcp_endpoint_accept(btl_proc->proc_endpoints[0],  
addr, sd)) {

OPAL_THREAD_UNLOCK(_proc->proc_lock);
return true;
}
___
svn mailing list
s...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/svn




smime.p7s
Description: S/MIME cryptographic signature

Re: [OMPI devel] RES: v pml question

[Aurélien Bouteiller]

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 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 like the following:
PML_SEND -> v_protocol -> crcpw -> ob1/cm

But since I have not tried this out I cannot say for sure. Let us know
if you have any problems.

Cheers,
Josh

On Jan 23, 2008, at 4:55 PM, Leonardo Fialho wrote:


I'm testing the v protocol just now. Anybody have plans to do a
message
wrapper mixing crcpw and v_protocol?

Leonardo Fialho
University Autonoma of Barcelona


___
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel


___
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel

Re: [OMPI devel] Orte collectives

[Ralph H Castain]

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".

Alternatively, you could just have a non-blocking recv sitting on each proc,
have it check to see "is this of interest to me", and release the message
memory that way. Might have to add the list of intended proc names to the
front of the message so each proc could decide whether or not to pay
attention to it...




On 1/29/08 12:37 PM, "Richard Graham"  wrote:

> 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 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 the job, but none of those procs needs
>> to invoke anything - we just deliver the message to the specified RML tag on
>> each proc. Of course, we assume that there is a recv (typically
>> non-blocking) posted on that tag (or that it will be posted eventually). If
>> not, then the message will just sit in the local oob waiting to be delivered
>> - no harm done, it just gets ignored.
>> 
>> Hope that helps. Let me know if you need some variant as I am adding (not
>> reducing or changing) grpcomm capabilities on the tmp branch.
>> 
>> Ralph
>> 
>> 
>> 
>> On 1/29/08 12:19 PM, "Richard Graham"  wrote:
>> 
>>> 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
>>> 
>>> ___
>>> devel mailing list
>>> de...@open-mpi.org
>>> http://www.open-mpi.org/mailman/listinfo.cgi/devel
>> 
>> 
>> ___
>> devel mailing list
>> de...@open-mpi.org
>> http://www.open-mpi.org/mailman/listinfo.cgi/devel
> 
> ___
> devel mailing list
> de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/devel

Re: [OMPI devel] RES: v pml question

[Josh Hursey]

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 like the following:

PML_SEND -> v_protocol -> crcpw -> ob1/cm

But since I have not tried this out I cannot say for sure. Let us know  
if you have any problems.


Cheers,
Josh

On Jan 23, 2008, at 4:55 PM, Leonardo Fialho wrote:

I'm testing the v protocol just now. Anybody have plans to do a  
message

wrapper mixing crcpw and v_protocol?

Leonardo Fialho
University Autonoma of Barcelona


___
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel

Re: [OMPI devel] Orte collectives

[Ralph H Castain]

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 the job, but none of those procs needs
to invoke anything - we just deliver the message to the specified RML tag on
each proc. Of course, we assume that there is a recv (typically
non-blocking) posted on that tag (or that it will be posted eventually). If
not, then the message will just sit in the local oob waiting to be delivered
- no harm done, it just gets ignored.

Hope that helps. Let me know if you need some variant as I am adding (not
reducing or changing) grpcomm capabilities on the tmp branch.

Ralph



On 1/29/08 12:19 PM, "Richard Graham"  wrote:

> 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
> 
> ___
> devel mailing list
> de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/devel

[OMPI devel] Orte collectives

[Richard Graham]

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

Re: [OMPI devel] vt compiler warnings and errors

[Matthias Jurenz]

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 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 should
I use another
variable ?


Matthias


On Di, 2008-01-29 at 09:19 -0500, 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 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
> 
> The output may be a bit hard to read -- for MTT builds, we separate  
> the stdout and stderr into 2 streams.  So you kinda have to merge them  
> in your head; sorry...
> 

--
Matthias Jurenz,
Center for Information Services and 
High Performance Computing (ZIH), TU Dresden, 
Willersbau A106, Zellescher Weg 12, 01062 Dresden
phone +49-351-463-31945, fax +49-351-463-37773


smime.p7s
Description: S/MIME cryptographic signature

Re: [OMPI devel] vt compiler warnings and errors

[Jeff Squyres]

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  
with

'--disable-mpi-io' which I reported earlier this morning.


Oops!  My bad -- Tim's right.

Note that there are a lot of compiler warnings in there, but that  
might be a side effect of the IO layer being disabled.


--
Jeff Squyres
Cisco Systems

[OMPI devel] Absoft is running OMPI MTT

[Jeff Squyres]

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 database.  Absoft is testing both stable and development  
snapshots of Open MPI with their compiler suite on several different  
platforms and operating systems.


MPI testing is not a core concern for a compiler company, but since  
Absoft products tend to be used in HPC environments, it benefits us  
all to ensure that Open MPI works properly with their products.  Not  
only does Absoft's testing give us early warning when we  
unintentionally break something in their environments, Absoft is  
actually testing some platforms that we were not already regularly  
testing (e.g., several flavors of OS X).


I would personally love to see similar collaborations with other  
compiler vendors.


Many thanks, Absoft!

--
Jeff Squyres
Cisco Systems

Re: [OMPI devel] Trunk borked

[Matthias Jurenz]

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 better solution...

To disable the vt-integration completely add the following option to the
configure script:

configure --enable-contrib-no-build=vt ...


Sorry again for this trouble!

Regards,
Matthias


On Di, 2008-01-29 at 07:37 -0500, Tim Prins wrote:

> 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 (first use in this function)
> vt_mpiwrap.c:3565: error: `datatype' undeclared (first use in this function)
> vt_mpiwrap.c:3565: error: `status' undeclared (first use in this function)
> vt_mpiwrap.c: At top level:
> vt_mpiwrap.c:3582: error: syntax error before "fh"
> vt_mpiwrap.c: In function `MPI_File_seek_shared':
> vt_mpiwrap.c:3596: error: `fh' undeclared (first use in this function)
> vt_mpiwrap.c:3596: error: `offset' undeclared (first use in this function)
> vt_mpiwrap.c:3596: error: `whence' undeclared (first use in this function)
> vt_mpiwrap.c: At top level:
> vt_mpiwrap.c:3613: error: syntax error before "fh"
> vt_mpiwrap.c: In function `MPI_File_write_ordered':
> vt_mpiwrap.c:3629: error: `fh' undeclared (first use in this function)
> vt_mpiwrap.c:3629: error: `buf' undeclared (first use in this function)
> vt_mpiwrap.c:3629: error: `count' undeclared (first use in this function)
> vt_mpiwrap.c:3629: error: `datatype' undeclared (first use in this function)
> vt_mpiwrap.c:3629: error: `status' undeclared (first use in this function)
> vt_mpiwrap.c: At top level:
> vt_mpiwrap.c:3646: error: syntax error before "fh"
> vt_mpiwrap.c: In function `MPI_File_write_shared':
> vt_mpiwrap.c:3662: error: `fh' undeclared (first use in this function)
> vt_mpiwrap.c:3662: error: `buf' undeclared (first use in this function)
> vt_mpiwrap.c:3662: error: `count' undeclared (first use in this function)
> vt_mpiwrap.c:3662: error: `datatype' undeclared (first use in this function)
> vt_mpiwrap.c:3662: error: `status' undeclared (first use in this function)
> rm -f libvt.a
> mv -f .deps/libvt_mpi_a-vt_user_region.Tpo 
> .deps/libvt_mpi_a-vt_user_region.Po
> ar cru libvt.a  vt_comp_gnu.o   vt_memhook.o vt_memreg.o vt_iowrap.o 
> vt_iowrap_helper.o
> rfg_regions.o rfg_filter.o rfg_groups.o vt_env.o vt_error.o vt_metmap.o 
> vt_otf_gen.o vt_otf_sum.o
> vt_otf_trc.o vt_pform_linux.o vt_pomp_base.o vt_strdup.o vt_thrd.o 
> vt_user_comment.o
> vt_user_count.o vt_user_region.o pomp_fwrapper_base.o
> mv -f .deps/libvt_mpi_a-vt_mpireq.Tpo .deps/libvt_mpi_a-vt_mpireq.Po
> vt_fmpiwrap.c: In function `vt_mpi_file_close_f':
> vt_fmpiwrap.c:2080: error: `MPI_File' undeclared (first use in this 
> function)
> vt_fmpiwrap.c:2080: error: (Each undeclared identifier is reported only once
> vt_fmpiwrap.c:2080: error: for each function it appears in.)
> vt_fmpiwrap.c:2080: error: syntax error before "l_fh"
> vt_fmpiwrap.c:2081: error: `l_fh' undeclared (first use in this function)
> vt_fmpiwrap.c: In function `vt_mpi_file_open_f':
> vt_fmpiwrap.c:2095: error: `MPI_File' undeclared (first use in this 
> function)
> vt_fmpiwrap.c:2095: error: syntax error before "l_fh"
> vt_fmpiwrap.c:2103: error: `l_fh' undeclared (first use in this function)
> make[5]: *** [libvt_mpi_a-vt_mpiwrap.o] Error 1
> make[5]: *** Waiting for unfinished jobs
> ranlib libvt.a
> make[5]: *** Waiting for unfinished jobs
> make[5]: *** [libvt_fmpi_a-vt_fmpiwrap.o] Error 1
> mv -f .deps/libvt_mpi_a-vt_iowrap.Tpo .deps/libvt_mpi_a-vt_iowrap.Po
> make[5]: Leaving directory
> `/san/homedirs/mpiteam/mtt-runs/odin/20080128-Nightly/pb_5/installs/VUuZ/src/openmpi-1.3a1r17289/ompi/contrib/vt/vt/vtlib'
> make[4]: *** [all-recursive] Error 1
> make[4]: Leaving directory
> `/san/homedirs/mpiteam/mtt-runs/odin/20080128-Nightly/pb_5/installs/VUuZ/src/openmpi-1.3a1r17289/ompi/contrib/vt/vt'
> make[3]: *** [all] Error 2
> make[3]: Leaving directory
> `/san/homedirs/mpiteam/mtt-runs/odin/20080128-Nightly/pb_5/installs/VUuZ/src/openmpi-1.3a1r17289/ompi/contrib/vt/vt'
> make[2]: *** [all-recursive] Error 1
> make[2]: Leaving directory
> `/san/homedirs/mpiteam/mtt-runs/odin/20080128-Nightly/pb_5/installs/VUuZ/src/openmpi-1.3a1r17289/ompi/contrib/vt'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory
> `/san/homedirs/mpiteam/mtt-runs/odin/20080128-Nightly/pb_5/installs/VUuZ/src/openmpi-1.3a1r17289/ompi'
> make: *** [all-recursive] Error 1
> 
> 
> Sorry for the messy output, we use make -j 6.
> 
> Thanks,
> 
> Tim
> 
> Andreas Knüpfer wrote:
> > On Tuesday 29 January 2008, George Bosilca wrote:
> >> 

Re: [OMPI devel] vt compiler warnings and errors

[Tim Prins]

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 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 with 
'--disable-mpi-io' which I reported earlier this morning.


Tim

[OMPI devel] vt compiler warnings and errors

[Jeff Squyres]

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:
  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

The output may be a bit hard to read -- for MTT builds, we separate  
the stdout and stderr into 2 streams.  So you kinda have to merge them  
in your head; sorry...


--
Jeff Squyres
Cisco Systems

Re: [OMPI devel] Configure error/warning in nightly tarball

[Josh Hursey]

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 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 seem to be remnants from the
autogen.sh script pointing to files that do not (and should not)
exist in the distribution.

-
shell$ ./configure --prefix=/foo/bar/
...
grep: ./orte/mca/gpr/proxy/configure.params: No such file or  
directory

grep: ./orte/mca/gpr/replica/configure.params: No such file or
directory
grep: ./orte/mca/gpr/null/configure.params: No such file or directory
-

Any thoughts on how to fix this? I was using the r17175 nightly
tarball.

Cheers,
Josh

___
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel



--
Jeff Squyres
Cisco Systems

___
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel

Re: [OMPI devel] Configure error/warning in nightly tarball

[Jeff Squyres]

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 seem to be remnants from the
autogen.sh script pointing to files that do not (and should not)
exist in the distribution.

-
shell$ ./configure --prefix=/foo/bar/
...
grep: ./orte/mca/gpr/proxy/configure.params: No such file or directory
grep: ./orte/mca/gpr/replica/configure.params: No such file or  
directory

grep: ./orte/mca/gpr/null/configure.params: No such file or directory
-

Any thoughts on how to fix this? I was using the r17175 nightly  
tarball.


Cheers,
Josh

___
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel



--
Jeff Squyres
Cisco Systems

Re: [OMPI devel] Trunk borked

[Matthias Jurenz]

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 defined


Fixed.


> /usr/bin/ld: cannot find -lz
> collect2: ld returned 1 exit status
> make[6]: *** [vtfilter] Error 1
> 


Please add the configure option 
--with-contrib-vt-flags="--with-otf-flags=--without-zlib
--with-otf-lib=-lotf"
This option will disable the zlib support of VampirTrace.
I'm working on a correct solution for this problem. 

Sorry for the trouble which comes with the VT integration... :-(


> Le 29 janv. 08 à 01:51, George Bosilca a écrit :
> 
> > 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,
> >>
> >> this problem should be fixed now...
> >> It seems that the symbol '__pos' is not available on every  
> >> platform. This isn't a problem, because
> >> it's only used for a debug control message.
> >>
> >> Regards,
> >> Matthias
> >>
> >>
> >> On Mo, 2008-01-28 at 09:41 -0500, Jeff Squyres wrote:
> >>>
> >>> Doh - this is Solaris on x86?  I think Terry said Solaris/sparc was
> >>> tested...
> >>>
> >>> VT guys -- can you check out what's going on?
> >>>
> >>>
> >>>
> >>> On Jan 28, 2008, at 9:36 AM, Adrian Knoth wrote:
> >>>
> >>> > On Mon, Jan 28, 2008 at 07:26:56AM -0700, Ralph H Castain wrote:
> >>> >
> >>> >> We seem to have a problem on the trunk this morning. I am  
> >>> building
> >>> >> on a
> >>> >
> >>> > There are more errors:
> >>> >
> >>> > /tmp/ompi/src/ompi/contrib/vt/vt/vtlib/vt_iowrap.c: In function
> >>> > `fsetpos':
> >>> > /tmp/ompi/src/ompi/contrib/vt/vt/vtlib/vt_iowrap.c:850: error:  
> >>> request
> >>> > for member `__pos' in something not a structure or union
> >>> > /tmp/ompi/src/ompi/contrib/vt/vt/vtlib/vt_iowrap.c: In function
> >>> > `fsetpos64':
> >>> > /tmp/ompi/src/ompi/contrib/vt/vt/vtlib/vt_iowrap.c:876: error:  
> >>> request
> >>> > for member `__pos' in something not a structure or union
> >>> > gmake[5]: *** [vt_iowrap.o] Error 1
> >>> > gmake[5]: Leaving directory
> >>> > `/tmp/ompi/build/SunOS-i86pc/ompi/ompi/contrib/vt/vt/vtlib'
> >>> > /tmp/ompi/src/ompi/contrib/vt/vt/vtlib/vt_iowrap.c: In function
> >>> > `fsetpos':
> >>> > /tmp/ompi/src/ompi/contrib/vt/vt/vtlib/vt_iowrap.c:850: error:  
> >>> request
> >>> > for member `__pos' in something not a structure or union
> >>> > /tmp/ompi/src/ompi/contrib/vt/vt/vtlib/vt_iowrap.c: In function
> >>> > `fsetpos64':
> >>> > /tmp/ompi/src/ompi/contrib/vt/vt/vtlib/vt_iowrap.c:876: error:  
> >>> request
> >>> > for member `__pos' in something not a structure or union
> >>> > gmake[5]: *** [vt_iowrap.o] Error 1
> >>> > gmake[5]: Leaving directory
> >>> > `/tmp/ompi/build/SunOS-i86pc/ompi/ompi/contrib/vt/vt/vtlib'
> >>> >
> >>> >
> >>> > Just my $0.02
> >>> >
> >>> > --
> >>> > Cluster and Metacomputing Working Group
> >>> > Friedrich-Schiller-Universität Jena, Germany
> >>> >
> >>> > private: http://adi.thur.de
> >>> > ___
> >>> > devel mailing list
> >>> > de...@open-mpi.org
> >>> > http://www.open-mpi.org/mailman/listinfo.cgi/devel
> >>>
> >>>
> >> --
> >> Matthias Jurenz,
> >> Center for Information Services and
> >> High Performance Computing (ZIH), TU Dresden,
> >> Willersbau A106, Zellescher Weg 12, 01062 Dresden
> >> phone +49-351-463-31945, fax +49-351-463-37773
> >> ___
> >> devel mailing list
> >> de...@open-mpi.org
> >> http://www.open-mpi.org/mailman/listinfo.cgi/devel
> >
> > ___
> > devel mailing list
> > de...@open-mpi.org
> > http://www.open-mpi.org/mailman/listinfo.cgi/devel
> 
> 
> ___
> devel mailing list
> de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/devel
> 

--
Matthias Jurenz,
Center for Information Services and 
High Performance Computing (ZIH), TU Dresden, 
Willersbau A106, Zellescher Weg 12, 01062 Dresden
phone +49-351-463-31945, fax +49-351-463-37773


smime.p7s
Description: S/MIME cryptographic signature

Re: [OMPI devel] Trunk borked

[Aurélien Bouteiller]

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
make[6]: *** [vtfilter] Error 1

Le 29 janv. 08 à 01:51, George Bosilca a écrit :

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,

this problem should be fixed now...
It seems that the symbol '__pos' is not available on every  
platform. This isn't a problem, because

it's only used for a debug control message.

Regards,
Matthias


On Mo, 2008-01-28 at 09:41 -0500, Jeff Squyres wrote:


Doh - this is Solaris on x86?  I think Terry said Solaris/sparc was
tested...

VT guys -- can you check out what's going on?



On Jan 28, 2008, at 9:36 AM, Adrian Knoth wrote:

> On Mon, Jan 28, 2008 at 07:26:56AM -0700, Ralph H Castain wrote:
>
>> We seem to have a problem on the trunk this morning. I am  
building

>> on a
>
> There are more errors:
>
> /tmp/ompi/src/ompi/contrib/vt/vt/vtlib/vt_iowrap.c: In function
> `fsetpos':
> /tmp/ompi/src/ompi/contrib/vt/vt/vtlib/vt_iowrap.c:850: error:  
request

> for member `__pos' in something not a structure or union
> /tmp/ompi/src/ompi/contrib/vt/vt/vtlib/vt_iowrap.c: In function
> `fsetpos64':
> /tmp/ompi/src/ompi/contrib/vt/vt/vtlib/vt_iowrap.c:876: error:  
request

> for member `__pos' in something not a structure or union
> gmake[5]: *** [vt_iowrap.o] Error 1
> gmake[5]: Leaving directory
> `/tmp/ompi/build/SunOS-i86pc/ompi/ompi/contrib/vt/vt/vtlib'
> /tmp/ompi/src/ompi/contrib/vt/vt/vtlib/vt_iowrap.c: In function
> `fsetpos':
> /tmp/ompi/src/ompi/contrib/vt/vt/vtlib/vt_iowrap.c:850: error:  
request

> for member `__pos' in something not a structure or union
> /tmp/ompi/src/ompi/contrib/vt/vt/vtlib/vt_iowrap.c: In function
> `fsetpos64':
> /tmp/ompi/src/ompi/contrib/vt/vt/vtlib/vt_iowrap.c:876: error:  
request

> for member `__pos' in something not a structure or union
> gmake[5]: *** [vt_iowrap.o] Error 1
> gmake[5]: Leaving directory
> `/tmp/ompi/build/SunOS-i86pc/ompi/ompi/contrib/vt/vt/vtlib'
>
>
> Just my $0.02
>
> --
> Cluster and Metacomputing Working Group
> Friedrich-Schiller-Universität Jena, Germany
>
> private: http://adi.thur.de
> ___
> devel mailing list
> de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/devel



--
Matthias Jurenz,
Center for Information Services and
High Performance Computing (ZIH), TU Dresden,
Willersbau A106, Zellescher Weg 12, 01062 Dresden
phone +49-351-463-31945, fax +49-351-463-37773
___
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel


___
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel