Re: [OMPI devel] RFC: Move the Open MPI communication infrastructure in OPAL

[Jeff Squyres (jsquyres)]

FWIW: I can't speak for other BTL maintainers, but I'm out of the office for 
the next week, and the usnic BTL will be standing still during that time.  Once 
I return, I will be making additional changes in the usnic BTL (new features, 
updates, ...etc.).

So if you have the cycles, doing it in the next week or so would be good 
because at least there will be no conflicts with usnic BTL concurrent 
development.  :-)




On Jul 10, 2014, at 2:56 PM, Ralph Castain  wrote:

> George: any update on when this will happen?
> 
> 
> On Jun 4, 2014, at 9:14 PM, George Bosilca  wrote:
> 
>> WHAT:Open our low-level communication infrastructure by moving all
>> necessary components
>>  (btl/rcache/allocator/mpool) down in OPAL
>> 
>> WHY: All the components required for inter-process communications are
>> currently deeply integrated in the OMPI
>> layer. Several groups/institutions have express interest
>> in having a more generic communication
>> infrastructure, without all the OMPI layer dependencies.
>> This communication layer should be made
>> available at a different software level, available to
>> all layers in the Open MPI software stack. As an
>> example, our ORTE layer could replace the current OOB
>> and instead use the BTL directly, gaining
>> access to more reactive network interfaces than TCP.
>> Similarly, external software libraries could take
>> advantage of our highly optimized AM (active message)
>> communication layer for their own purpose.
>> 
>> UTK with support from Sandia, developped a version of
>> Open MPI where the entire communication
>> infrastucture has been moved down to OPAL
>> (btl/rcache/allocator/mpool). Most of the moved
>> components have been updated to match the new schema,
>> with few exceptions (mainly BTLs
>> where I have no way of compiling/testing them). Thus,
>> the completion of this RFC is tied to
>> being able to completing this move for all BTLs. For
>> this we need help from the rest of the Open MPI
>> community, especially those supporting some of the BTLs.
>> A non-exhaustive list of BTLs that
>> qualify here is: mx, portals4, scif, udapl, ugni, usnic.
>> 
>> WHERE:  bitbucket.org/bosilca/ompi-btl (updated today with respect to
>> trunk r31952)
>> 
>> TIMEOUT: After all the BTLs have been amended to match the new
>> location and usage. We will discuss
>> the last bits regarding this RFC at the Open MPI
>> developers meeting in Chicago, June 24-26. The
>> RFC will become final only after the meeting.
>> ___
>> devel mailing list
>> de...@open-mpi.org
>> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
>> Link to this post: 
>> http://www.open-mpi.org/community/lists/devel/2014/06/14974.php
> 
> ___
> devel mailing list
> de...@open-mpi.org
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> Link to this post: 
> http://www.open-mpi.org/community/lists/devel/2014/07/15100.php


-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

Re: [OMPI devel] openmpi.spec

[Jeff Squyres (jsquyres)]

Mike and I talked in IM.  The results of our chat was Mike's commit:

https://svn.open-mpi.org/trac/ompi/changeset/32205


On Jul 10, 2014, at 9:57 AM, Mike Dubman  wrote:

> 
> Hi,
> The following commit https://svn.open-mpi.org/trac/ompi/changeset/32147 does 
> some harm:
> 
> the line 202 in the change causes openmpi.src.rpm to contain arch in the rpm 
> name, i.e. openmpi-1.8.2a1-1.el6.src.rpm
> 
> The src.rpm should be arch agnostic.
> 
> what do you think?
> 
> Thanks
> ___
> devel mailing list
> de...@open-mpi.org
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> Link to this post: 
> http://www.open-mpi.org/community/lists/devel/2014/07/15097.php


-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

Re: [OMPI devel] trunk and fortran errors

[Jeff Squyres (jsquyres)]

Mike / Gilles --

As of r32204, this should be fixed.  Please let me know if it now works for you.

Thanks.



On Jul 10, 2014, at 8:27 AM, Jeff Squyres (jsquyres)  wrote:

> I'm back in the office today and will be checking into this. 
> 
> Sent from my phone. No type good. 
> 
>> On Jul 10, 2014, at 5:41 AM, "Gilles Gouaillardet" 
>>  wrote:
>> 
>> On CentOS 5.x, gfortran is unable to compile this simple program :
>> 
>> subroutine foo ()
>> use, intrinsic :: iso_c_binding, only : c_ptr
>> end subroutine foo
>> 
>> an other workaround is to install gfortran 4.4
>> (yum install gcc44-gfortran)
>> and configure with
>> FC=gfortran44
>> 
>> 
>>> On 2014/07/09 19:46, Jeff Squyres (jsquyres) wrote:
>>> This is almost certainly due to r32162 (Fortran commit from last night).
>>> [...]
>>> For the moment/as a workaround, use --disable-mpi-fortran in your builds if 
>>> you are building with an older gfortran.
>> 
>> ___
>> devel mailing list
>> de...@open-mpi.org
>> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
>> Link to this post: 
>> http://www.open-mpi.org/community/lists/devel/2014/07/15089.php
> ___
> devel mailing list
> de...@open-mpi.org
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> Link to this post: 
> http://www.open-mpi.org/community/lists/devel/2014/07/15092.php


-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

[OMPI devel] RFC: BTL Interface Change (2 of 5)

[Nathan Hjelm]

What: Change the descriptor completion callback function to include
cbdata and context pointers.

Old callback:

typedef void (*mca_btl_base_completion_fn_t)(
struct mca_btl_base_module_t* module,
struct mca_btl_base_endpoint_t* endpoint,
struct mca_btl_base_descriptor_t* descriptor,
int status);


New callback:

typedef void (*mca_btl_base_completion_fn_t)(
struct mca_btl_base_module_t* module,
struct mca_btl_base_endpoint_t* endpoint,
struct mca_btl_base_descriptor_t* descriptor,
void *cbdata, void *context, int status);


Why: The BTL interface provides support for using a single descriptor
with multiple concurrent RDMA operations. BTLs support this feature if
the following flag is not set:

/** RDMA put/get calls must have a matching prepare_{src,dst} call
on the target with the same base (and possibly bound). */
#define MCA_BTL_FLAGS_RDMA_MATCHED0x0040


The problem is that in order to pass back the correct callback data and
context to the completion function BTLs need to modify the
descriptor. This could be a disaster in a multi-threaded application if
one thread is calling the completion callback while another thread is
preparing to start a put/get operation. To avoid issues it is better to
provide the callback data as seperate arguments.

The change is straightforward and the commit will update all BTLs and
BTL users to use the new completion callback signature.


When: As this was discussed at the developer's meeting last month I am
setting a short timeout for this RFC. This times out next Wed (July
16).


I would really like feedback on this change. Can it be improved? Should
the segment data be passed back to the function (not something I need
for RMA but might be useful elsewhere)? Would it be better to remove the
simultaneous RDMA feature in favor of a lightweight descriptor clone (I
have this implemented as well and I have no problem with providing
both features)?


This is another is a series of RFCs to improve (I hope) the BTL
interface for one-sided operations. The next RFC will be on the
one-sided BTL interface.

-Nathan Hjelm
HPC-5, LANL


pgptPwvMIBf_u.pgp
Description: PGP signature

Re: [OMPI devel] RFC: Move the Open MPI communication infrastructure in OPAL

[Ralph Castain]

George: any update on when this will happen?


On Jun 4, 2014, at 9:14 PM, George Bosilca  wrote:

> WHAT:Open our low-level communication infrastructure by moving all
> necessary components
>   (btl/rcache/allocator/mpool) down in OPAL
> 
> WHY: All the components required for inter-process communications are
> currently deeply integrated in the OMPI
>  layer. Several groups/institutions have express interest
> in having a more generic communication
>  infrastructure, without all the OMPI layer dependencies.
> This communication layer should be made
>  available at a different software level, available to
> all layers in the Open MPI software stack. As an
>  example, our ORTE layer could replace the current OOB
> and instead use the BTL directly, gaining
>  access to more reactive network interfaces than TCP.
> Similarly, external software libraries could take
>  advantage of our highly optimized AM (active message)
> communication layer for their own purpose.
> 
>  UTK with support from Sandia, developped a version of
> Open MPI where the entire communication
>  infrastucture has been moved down to OPAL
> (btl/rcache/allocator/mpool). Most of the moved
>  components have been updated to match the new schema,
> with few exceptions (mainly BTLs
>  where I have no way of compiling/testing them). Thus,
> the completion of this RFC is tied to
>  being able to completing this move for all BTLs. For
> this we need help from the rest of the Open MPI
>  community, especially those supporting some of the BTLs.
> A non-exhaustive list of BTLs that
>  qualify here is: mx, portals4, scif, udapl, ugni, usnic.
> 
> WHERE:  bitbucket.org/bosilca/ompi-btl (updated today with respect to
> trunk r31952)
> 
> TIMEOUT: After all the BTLs have been amended to match the new
> location and usage. We will discuss
>  the last bits regarding this RFC at the Open MPI
> developers meeting in Chicago, June 24-26. The
>  RFC will become final only after the meeting.
> ___
> devel mailing list
> de...@open-mpi.org
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> Link to this post: 
> http://www.open-mpi.org/community/lists/devel/2014/06/14974.php

Re: [OMPI devel] hwloc and pmi

[Nathan Hjelm]

Nope, just added a missing file to the tarball.

-Nathan

On Thu, Jul 10, 2014 at 06:54:19AM -0700, Ralph Castain wrote:
>IIRC, I thought I saw a change to that makefile.am flow thru yesterday?
>Could be there was an error in it
>On Jul 10, 2014, at 5:26 AM, Jeff Squyres (jsquyres) 
>wrote:
> 
>  Shouldn't be - PMI should be linking against the internal hwloc. 
>  I'm AFK and can't look at this. Have a look at other components that use
>  hwloc and copy their header file setup and make file.am setup. 
> 
>  Sent from my phone. No type good. 
>  On Jul 10, 2014, at 8:22 AM, "Mike Dubman" 
>  wrote:
> 
>Hi guys,
>jenkins node failing on this.
>is hwloc-devel now required to be available as part of distro?
>Thanks
>M
> 
>  15:14:11 make[3]: Leaving directory 
> `/scrap/jenkins/scrap/workspace/hpc-ompi-shmem/label/hpc-test-node/opal'
>  15:14:11 make[2]: Leaving directory 
> `/scrap/jenkins/scrap/workspace/hpc-ompi-shmem/label/hpc-test-node/opal'
>  15:14:11 Making install in mca/common/pmi
>  15:14:11 make[2]: Entering directory 
> `/scrap/jenkins/scrap/workspace/hpc-ompi-shmem/label/hpc-test-node/opal/mca/common/pmi'
>  15:14:11   CC   common_pmi.lo
>  15:14:11   CCLD libmca_common_pmi.la
>  15:14:11 /usr/bin/ld: cannot find -lhwloc
>  15:14:11 collect2: ld returned 1 exit status
>  15:14:11 make[2]: *** [libmca_common_pmi.la] Error 1
>  15:14:11 make[2]: Leaving directory 
> `/scrap/jenkins/scrap/workspace/hpc-ompi-shmem/label/hpc-test-node/opal/mca/common/pmi'
> 
>___
>devel mailing list
>de...@open-mpi.org
>Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
>Link to this post:
>http://www.open-mpi.org/community/lists/devel/2014/07/15090.php
> 
>  ___
>  devel mailing list
>  de...@open-mpi.org
>  Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
>  Link to this post:
>  http://www.open-mpi.org/community/lists/devel/2014/07/15091.php

> ___
> devel mailing list
> de...@open-mpi.org
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> Link to this post: 
> http://www.open-mpi.org/community/lists/devel/2014/07/15096.php



pgpIFArTeVvWZ.pgp
Description: PGP signature

Re: [OMPI devel] [OMPI svn-full] svn:open-mpi r32166 - in trunk: ompi/mca/coll/fca ompi/mca/coll/hcoll ompi/mca/mtl/mxm ompi/tools/ompi_info opal/mca/base opal/runtime

[Jeff Squyres (jsquyres)]

Two quibbles with this commit:

1. Can the help strings for the various components be updated to use proper 
grammar and capitalization?  For example:

Version of the libfca library ompi compiled with

change to:

Version of the libfca library with which Open MPI was compiled

2. I'm not a fan of --type automatically changing the level to 9.  --type 
should be orthogonal to level; --type should just set a filter to only show 
variables of a certain type -- nothing else.



On Jul 8, 2014, at 9:37 PM, svn-commit-mai...@open-mpi.org wrote:

> Author: jladd (Joshua Ladd)
> Date: 2014-07-08 21:37:23 EDT (Tue, 08 Jul 2014)
> New Revision: 32166
> URL: https://svn.open-mpi.org/trac/ompi/changeset/32166
> 
> Log:
> Opal: Add a new MCA variable type "version_string". Also add a 
> new flag to ompi_info that allows a user to print all MCA variables of a 
> specific type.  
> 
> --type version_string
> 
> This command will print all MCA variables of type version_string.
> 
> This feature was developed by Elena Shipunova and was reviewed by Josh Ladd.
> 
> Text files modified: 
>   trunk/ompi/mca/coll/fca/coll_fca_component.c | 4 +- 
>  
>   trunk/ompi/mca/coll/hcoll/coll_hcoll_component.c | 4 +- 
>  
>   trunk/ompi/mca/mtl/mxm/mtl_mxm_component.c   | 4 +- 
>  
>   trunk/ompi/tools/ompi_info/ompi_info.1in |12    
>  
>   trunk/ompi/tools/ompi_info/ompi_info.c   | 4 ++ 
>  
>   trunk/opal/mca/base/mca_base_var.c   |22 +- 
>  
>   trunk/opal/mca/base/mca_base_var.h   | 3 ++ 
>  
>   trunk/opal/runtime/opal_info_support.c   |59 
> 
>   trunk/opal/runtime/opal_info_support.h   | 2 +  
>  
>   9 files changed, 100 insertions(+), 14 deletions(-)
> 
> Modified: trunk/ompi/mca/coll/fca/coll_fca_component.c
> ==
> --- trunk/ompi/mca/coll/fca/coll_fca_component.c  Tue Jul  8 21:24:53 
> 2014(r32165)
> +++ trunk/ompi/mca/coll/fca/coll_fca_component.c  2014-07-08 21:37:23 EDT 
> (Tue, 08 Jul 2014)  (r32166)
> @@ -1411,7 +1411,7 @@
> (void) mca_base_component_var_register(c,
> MCA_COMPILETIME_VER,
> "Version of the libfca library ompi compiled with",
> -MCA_BASE_VAR_TYPE_STRING,
> +MCA_BASE_VAR_TYPE_VERSION_STRING,
> NULL, 0, 0,
> OPAL_INFO_LVL_3,
> MCA_BASE_VAR_SCOPE_READONLY,
> @@ -1420,7 +1420,7 @@
> (void) mca_base_component_var_register(c,
> MCA_RUNTIME_VER,
> "Version of the libfca library ompi run with",
> -MCA_BASE_VAR_TYPE_STRING,
> +MCA_BASE_VAR_TYPE_VERSION_STRING,
> NULL, 0, 0,
> OPAL_INFO_LVL_3,
> MCA_BASE_VAR_SCOPE_READONLY,
> 
> Modified: trunk/ompi/mca/coll/hcoll/coll_hcoll_component.c
> ==
> --- trunk/ompi/mca/coll/hcoll/coll_hcoll_component.c  Tue Jul  8 21:24:53 
> 2014(r32165)
> +++ trunk/ompi/mca/coll/hcoll/coll_hcoll_component.c  2014-07-08 21:37:23 EDT 
> (Tue, 08 Jul 2014)  (r32166)
> @@ -211,7 +211,7 @@
> 
> mca_base_component_var_register(_coll_hcoll_component.super.collm_version,
> MCA_COMPILETIME_VER,
> "Version of the libhcoll library ompi compiled with",
> -MCA_BASE_VAR_TYPE_STRING,
> +MCA_BASE_VAR_TYPE_VERSION_STRING,
> NULL, 0, 0,
> OPAL_INFO_LVL_3,
> MCA_BASE_VAR_SCOPE_READONLY,
> @@ -220,7 +220,7 @@
> 
> mca_base_component_var_register(_coll_hcoll_component.super.collm_version,
> MCA_RUNTIME_VER,
> "Version of the libhcoll library ompi run with",
> -MCA_BASE_VAR_TYPE_STRING,
> +MCA_BASE_VAR_TYPE_VERSION_STRING,
> NULL, 0, 0,
> OPAL_INFO_LVL_3,
> MCA_BASE_VAR_SCOPE_READONLY,
> 
> Modified: trunk/ompi/mca/mtl/mxm/mtl_mxm_component.c
> ==
> --- trunk/ompi/mca/mtl/mxm/mtl_mxm_component.cTue Jul  8 21:24:53 
> 2014(r32165)
> +++ trunk/ompi/mca/mtl/mxm/mtl_mxm_component.c2014-07-08 21:37:23 EDT 
> (Tue, 08 Jul 2014)  (r32166)
> @@ -96,7 +96,7 @@
> (void) mca_base_component_var_register(c,
> MCA_COMPILETIME_VER,
> "Version of the libmxm library ompi compiled with",
> -MCA_BASE_VAR_TYPE_STRING,
> +MCA_BASE_VAR_TYPE_VERSION_STRING,
> NULL, 0, 0,
> OPAL_INFO_LVL_3,
> 

[OMPI devel] openmpi.spec

[Mike Dubman]

Hi,
The following commit https://svn.open-mpi.org/trac/ompi/changeset/32147
does some harm:

the line 202 in the change causes openmpi.src.rpm to contain arch in the
rpm name, i.e. openmpi-1.8.2a1-1.el6.src.rpm

The src.rpm should be arch agnostic.

what do you think?

Thanks

Re: [OMPI devel] hwloc and pmi

[Ralph Castain]

IIRC, I thought I saw a change to that makefile.am flow thru yesterday? Could 
be there was an error in it

On Jul 10, 2014, at 5:26 AM, Jeff Squyres (jsquyres)  wrote:

> Shouldn't be - PMI should be linking against the internal hwloc. 
> 
> I'm AFK and can't look at this. Have a look at other components that use 
> hwloc and copy their header file setup and make file.am setup. 
> 
> Sent from my phone. No type good. 
> 
> On Jul 10, 2014, at 8:22 AM, "Mike Dubman"  wrote:
> 
>> 
>> Hi guys,
>> 
>> jenkins node failing on this.
>> is hwloc-devel now required to be available as part of distro?
>> 
>> Thanks
>> M
>> 
>> 15:14:11 make[3]: Leaving directory 
>> `/scrap/jenkins/scrap/workspace/hpc-ompi-shmem/label/hpc-test-node/opal'
>> 15:14:11 make[2]: Leaving directory 
>> `/scrap/jenkins/scrap/workspace/hpc-ompi-shmem/label/hpc-test-node/opal'
>> 15:14:11 Making install in mca/common/pmi
>> 15:14:11 make[2]: Entering directory 
>> `/scrap/jenkins/scrap/workspace/hpc-ompi-shmem/label/hpc-test-node/opal/mca/common/pmi'
>> 15:14:11   CC   common_pmi.lo
>> 15:14:11   CCLD libmca_common_pmi.la
>> 15:14:11 /usr/bin/ld: cannot find -lhwloc
>> 15:14:11 collect2: ld returned 1 exit status
>> 15:14:11 make[2]: *** [libmca_common_pmi.la] Error 1
>> 15:14:11 make[2]: Leaving directory 
>> `/scrap/jenkins/scrap/workspace/hpc-ompi-shmem/label/hpc-test-node/opal/mca/common/pmi'
>> 
>> ___
>> devel mailing list
>> de...@open-mpi.org
>> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
>> Link to this post: 
>> http://www.open-mpi.org/community/lists/devel/2014/07/15090.php
> ___
> devel mailing list
> de...@open-mpi.org
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> Link to this post: 
> http://www.open-mpi.org/community/lists/devel/2014/07/15091.php

Re: [OMPI devel] Shared library version numbers for 1.8.2

[Mike Dubman]

confirmed.
Thanks


On Thu, Jul 10, 2014 at 3:31 PM, Jeff Squyres (jsquyres)  wrote:

> Bert: good catch, thanks
>
> Mellanox: can you confirm that this change was required?
>
> Sent from my phone. No type good.
>
> > On Jul 9, 2014, at 4:59 PM, "Ralph Castain"  wrote:
> >
> > Ouch - yes, we definitely should roll it to 4:0:0. I gather the ABI
> change was required to comply with the spec. I normally would refuse to
> allow an ABI change during a stable release series, but have given more
> latitude to OSHMEM due to its relatively new inclusion and the need to get
> it into compliance.
> >
> >
> >
> >> On Jul 9, 2014, at 1:25 PM, Bert Wesarg 
> wrote:
> >>
> >> Quoting "Jeff Squyres (jsquyres)" :
> >>> Here's what I think VERSION should be for 1.8.2:
> >>>
> >>>   https://svn.open-mpi.org/trac/ompi/changeset/32165
> >>>
> >>> I left comments in the VERSION file as to why I think each version
> number should change.
> >>>
> >>> Can someone please verify that this work is correct?  If so, we can
> remove the comments (before the final 1.8.2 release).
> >>
> >>> -liboshmem_so_version=2:0:1
> >>> +liboshmem_so_version=3:0:2
> >>> +# lib changed
> >>> +# added interfaces: shmem_int32_finc, shmem_int64_finc, profiling
> >>
> >> I think liboshmem_so_version should get 4:0:0 as the return type of
> shmem_finalize changed from int to void.
> >>
> >> Here is the trunk commit:
> >>
> >> https://svn.open-mpi.org/trac/ompi/changeset/31413
> >>
> >> And here the CMR commit:
> >>
> >> https://svn.open-mpi.org/trac/ompi/changeset/31758
> >>
> >> Regards,
> >> Bert
> >>
> >>>
> >>> --
> >>> Jeff Squyres
> >> --
> >> Dipl.-Inf. Bert Wesarg
> >> wiss. Mitarbeiter
> >>
> >> Technische Universität Dresden
> >> Zentrum für Informationsdienste und Hochleistungsrechnen (ZIH)
> >> 01062 Dresden
> >> Tel.: +49 (351) 463-42451
> >> Fax: +49 (351) 463-37773
> >> E-Mail: bert.wes...@tu-dresden.de
> >>
> >> ___
> >> devel mailing list
> >> de...@open-mpi.org
> >> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> >> Link to this post:
> http://www.open-mpi.org/community/lists/devel/2014/07/15083.php
> >
> > ___
> > devel mailing list
> > de...@open-mpi.org
> > Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> > Link to this post:
> http://www.open-mpi.org/community/lists/devel/2014/07/15084.php
> ___
> devel mailing list
> de...@open-mpi.org
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> Link to this post:
> http://www.open-mpi.org/community/lists/devel/2014/07/15093.php
>

Re: [OMPI devel] Shared library version numbers for 1.8.2

[Jeff Squyres (jsquyres)]

Bert: good catch, thanks

Mellanox: can you confirm that this change was required?

Sent from my phone. No type good. 

> On Jul 9, 2014, at 4:59 PM, "Ralph Castain"  wrote:
> 
> Ouch - yes, we definitely should roll it to 4:0:0. I gather the ABI change 
> was required to comply with the spec. I normally would refuse to allow an ABI 
> change during a stable release series, but have given more latitude to OSHMEM 
> due to its relatively new inclusion and the need to get it into compliance.
> 
> 
> 
>> On Jul 9, 2014, at 1:25 PM, Bert Wesarg  wrote:
>> 
>> Quoting "Jeff Squyres (jsquyres)" :
>>> Here's what I think VERSION should be for 1.8.2:
>>> 
>>>   https://svn.open-mpi.org/trac/ompi/changeset/32165
>>> 
>>> I left comments in the VERSION file as to why I think each version number 
>>> should change.
>>> 
>>> Can someone please verify that this work is correct?  If so, we can remove 
>>> the comments (before the final 1.8.2 release).
>> 
>>> -liboshmem_so_version=2:0:1
>>> +liboshmem_so_version=3:0:2
>>> +# lib changed
>>> +# added interfaces: shmem_int32_finc, shmem_int64_finc, profiling
>> 
>> I think liboshmem_so_version should get 4:0:0 as the return type of 
>> shmem_finalize changed from int to void.
>> 
>> Here is the trunk commit:
>> 
>> https://svn.open-mpi.org/trac/ompi/changeset/31413
>> 
>> And here the CMR commit:
>> 
>> https://svn.open-mpi.org/trac/ompi/changeset/31758
>> 
>> Regards,
>> Bert
>> 
>>> 
>>> --
>>> Jeff Squyres
>> -- 
>> Dipl.-Inf. Bert Wesarg
>> wiss. Mitarbeiter
>> 
>> Technische Universität Dresden
>> Zentrum für Informationsdienste und Hochleistungsrechnen (ZIH)
>> 01062 Dresden
>> Tel.: +49 (351) 463-42451
>> Fax: +49 (351) 463-37773
>> E-Mail: bert.wes...@tu-dresden.de
>> 
>> ___
>> devel mailing list
>> de...@open-mpi.org
>> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
>> Link to this post: 
>> http://www.open-mpi.org/community/lists/devel/2014/07/15083.php
> 
> ___
> devel mailing list
> de...@open-mpi.org
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> Link to this post: 
> http://www.open-mpi.org/community/lists/devel/2014/07/15084.php

Re: [OMPI devel] trunk and fortran errors

[Jeff Squyres (jsquyres)]

I'm back in the office today and will be checking into this. 

Sent from my phone. No type good. 

> On Jul 10, 2014, at 5:41 AM, "Gilles Gouaillardet" 
>  wrote:
> 
> On CentOS 5.x, gfortran is unable to compile this simple program :
> 
> subroutine foo ()
>  use, intrinsic :: iso_c_binding, only : c_ptr
> end subroutine foo
> 
> an other workaround is to install gfortran 4.4
> (yum install gcc44-gfortran)
> and configure with
> FC=gfortran44
> 
> 
>> On 2014/07/09 19:46, Jeff Squyres (jsquyres) wrote:
>> This is almost certainly due to r32162 (Fortran commit from last night).
>> [...]
>> For the moment/as a workaround, use --disable-mpi-fortran in your builds if 
>> you are building with an older gfortran.
> 
> ___
> devel mailing list
> de...@open-mpi.org
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> Link to this post: 
> http://www.open-mpi.org/community/lists/devel/2014/07/15089.php

Re: [OMPI devel] hwloc and pmi

[Jeff Squyres (jsquyres)]

Shouldn't be - PMI should be linking against the internal hwloc.

I'm AFK and can't look at this. Have a look at other components that use hwloc 
and copy their header file setup and make file.am setup.

Sent from my phone. No type good.

On Jul 10, 2014, at 8:22 AM, "Mike Dubman" 
> wrote:


Hi guys,

jenkins node failing on this.
is hwloc-devel now required to be available as part of distro?

Thanks
M


15:14:11 make[3]: Leaving directory 
`/scrap/jenkins/scrap/workspace/hpc-ompi-shmem/label/hpc-test-node/opal'
15:14:11 make[2]: Leaving directory 
`/scrap/jenkins/scrap/workspace/hpc-ompi-shmem/label/hpc-test-node/opal'
15:14:11 Making install in mca/common/pmi
15:14:11 make[2]: Entering directory 
`/scrap/jenkins/scrap/workspace/hpc-ompi-shmem/label/hpc-test-node/opal/mca/common/pmi'
15:14:11   CC   common_pmi.lo
15:14:11   CCLD libmca_common_pmi.la
15:14:11 /usr/bin/ld: cannot find -lhwloc
15:14:11 collect2: ld returned 1 exit status
15:14:11 make[2]: *** [libmca_common_pmi.la] Error 
1
15:14:11 make[2]: Leaving directory 
`/scrap/jenkins/scrap/workspace/hpc-ompi-shmem/label/hpc-test-node/opal/mca/common/pmi'


___
devel mailing list
de...@open-mpi.org
Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
Link to this post: 
http://www.open-mpi.org/community/lists/devel/2014/07/15090.php

[OMPI devel] hwloc and pmi

[Mike Dubman]

Hi guys,

jenkins node failing on this.
is hwloc-devel now required to be available as part of distro?

Thanks
M

*15:14:11* make[3]: Leaving directory
`/scrap/jenkins/scrap/workspace/hpc-ompi-shmem/label/hpc-test-node/opal'*15:14:11*
make[2]: Leaving directory
`/scrap/jenkins/scrap/workspace/hpc-ompi-shmem/label/hpc-test-node/opal'*15:14:11*
Making install in mca/common/pmi*15:14:11* make[2]: Entering directory
`/scrap/jenkins/scrap/workspace/hpc-ompi-shmem/label/hpc-test-node/opal/mca/common/pmi'*15:14:11*
  CC   common_pmi.lo*15:14:11*   CCLD
libmca_common_pmi.la*15:14:11* /usr/bin/ld: cannot find
-lhwloc*15:14:11* collect2: ld returned 1 exit status*15:14:11*
make[2]: *** [libmca_common_pmi.la] Error 1*15:14:11* make[2]: Leaving
directory 
`/scrap/jenkins/scrap/workspace/hpc-ompi-shmem/label/hpc-test-node/opal/mca/common/pmi'

Re: [OMPI devel] trunk and fortran errors

[Gilles Gouaillardet]

On CentOS 5.x, gfortran is unable to compile this simple program :

subroutine foo ()
  use, intrinsic :: iso_c_binding, only : c_ptr
end subroutine foo

an other workaround is to install gfortran 4.4
(yum install gcc44-gfortran)
and configure with
FC=gfortran44


On 2014/07/09 19:46, Jeff Squyres (jsquyres) wrote:
> This is almost certainly due to r32162 (Fortran commit from last night).
> [...]
> For the moment/as a workaround, use --disable-mpi-fortran in your builds if 
> you are building with an older gfortran.