Re: [OMPI devel] master broken on (at least) OpenBSD-6

2016-09-22 Thread Gilles Gouaillardet 

Thanks Paul,


i fixed that (and 4 more errors that popped up) in the attached patch


i opened https://github.com/open-mpi/ompi/pull/2110, but will likely 
merge the first 3 commits quite soon.


/* the last two commits fix autogen.pl on OpenBSD 6.0 and need a review */

so you'd better use the attached patch for now.


/* you need to run autogen.pl, if you do not have recent autotools on 
your OpenBSD 6.0 box, you can


apply the patch on an other platform, ./autogen.pl && ./configure && 
make dist, and copy the generated tarball to


OpenBSD */


Cheers,


Gilles



On 9/23/2016 3:33 AM, Paul Hargrove wrote:
When trying to test PR2107 on OpenBSD-6 I was blocked by the following 
error, which is also present in 'master'.


../../../ompi/opal/util/if.c: In function 'opal_ifisloopback':
../../../ompi/opal/util/if.c:710: error: 'IFF_LOOPBACK' undeclared 
(first use in this function)
../../../ompi/opal/util/if.c:710: error: (Each undeclared identifier 
is reported only once

../../../ompi/opal/util/if.c:710: error: for each function it appears in.)
../../../ompi/opal/util/if.c: In function 'opal_ifgetaliases':
../../../ompi/opal/util/if.c:791: error: 'IFF_LOOPBACK' undeclared 
(first use in this function)


The constant IFF_LOOPBACK is defined in net/if.h, as expected.
However, opal_config.h says:

/* #undef HAVE_NET_IF_H */


Related to that is the following output from configure:

checking net/if.h usability... no
checking net/if.h presence... yes
configure: WARNING: net/if.h: present but cannot be compiled
configure: WARNING: net/if.h: check for missing prerequisite
headers?
configure: WARNING: net/if.h: see the Autoconf documentation
configure: WARNING: net/if.h: section "Present But Cannot Be
Compiled"
configure: WARNING: net/if.h: proceeding with the compiler's result
configure: WARNING: ##
-- ##
configure: WARNING: ## Report this to
http://www.open-mpi.org/community/help/ ##
configure: WARNING: ##
-- ##
checking for net/if.h... no


Details from config.log:

configure:62402: checking net/if.h usability
configure:62402: gcc -std=gnu99 -c -O3 -DNDEBUG -finline-functions
-fno-strict-aliasing  conftest.c >&5
In file included from conftest.c:433:
/usr/include/net/if.h:358: error: field 'ifru_addr' has incomplete
type
/usr/include/net/if.h:359: error: field 'ifru_dstaddr' has
incomplete type
/usr/include/net/if.h:360: error: field 'ifru_broadaddr' has
incomplete type
/usr/include/net/if.h:387: error: field 'ifrau_addr' has
incomplete type
/usr/include/net/if.h:393: error: field 'ifra_dstaddr' has
incomplete type
/usr/include/net/if.h:395: error: field 'ifra_mask' has incomplete
type
/usr/include/net/if.h:438: error: field 'addr' has incomplete type
/usr/include/net/if.h:439: error: field 'dstaddr' has incomplete type
/usr/include/net/if.h:445: error: expected
specifier-qualifier-list before 'sa_family_t'
In file included from /usr/include/net/if.h:454,
 from conftest.c:433:
/usr/include/net/if_arp.h:79: error: field 'arp_pa' has incomplete
type
/usr/include/net/if_arp.h:80: error: field 'arp_ha' has incomplete
type


Man page for if_nametoindex() and friends show:

 #include 
 #include 
 #include 


It looks like configure.ac  is *trying* to deal 
with the sys/socket.h dependency:


# Needed to work around Darwin requiring sys/socket.h for
# net/if.h
AC_CHECK_HEADERS([net/if.h], [], [],
[#include 
#if STDC_HEADERS
# include 
# include 
#else
# if HAVE_STDLIB_H
#  include 
# endif
#endif
#if HAVE_SYS_SOCKET_H
# include 
#endif
])


However, config.log suggests that the previous failure has been 
cached, making this (second) test for net/if.h a no-op:


configure:62453: checking for net/if.h
configure:62453: result: no



-Paul

--
Paul H. Hargrove phhargr...@lbl.gov 
Computer Languages & Systems Software (CLaSS) Group
Computer Science Department   Tel: +1-510-495-2352
Lawrence Berkeley National Laboratory Fax: +1-510-486-6900


___
devel mailing list
devel@lists.open-mpi.org
https://rfd.newmexicoconsortium.org/mailman/listinfo/devel


diff --git a/config/ompi_fortran_check.m4 b/config/ompi_fortran_check.m4
index 46ecf24..51d1e03 100644
--- a/config/ompi_fortran_check.m4
+++ b/config/ompi_fortran_check.m4
@@ -11,7 +11,7 @@ dnl University of Stuttgart.  All 
rights reserved.
 dnl Copyright (c) 2004-2005 The Regents of the University of California.
 dnl All rights reserved.
 dnl Copyright (c) 2011-2012 Cisco Systems, Inc.  All rights reserved.
-dnl Copyright (c) 2015

Re: [OMPI devel] ompi-release repo is now closed; long live the ompi repo!

2016-09-22 Thread Josh Hursey 
One set of bot: commands will still work. Those associated with Jenkins, in
general, should still work. So:
bot:retest
bot:ibm:retest
bot:lanl:retest

Those bot: commands are processed as part of the Jenkins setup and are not
reliant on the IU webhook.

Note: The IBM CI is not currently setup to watch the release branches now
that they have moved. I'll try to fix that tomorrow when I'm back in the
office.


On Tue, Sep 20, 2016 at 8:20 PM, Jeff Squyres (jsquyres)  wrote:

> All the branches from ompi-release have now been merged back into the ompi
> repo.
>
> (amusingly, we all got a gitdub email for the creation of each old release
> branch)
>
> The ompi-release repo is now effectively closed.  It will not be deleted,
> however, so that old links won't go stale, and old conversations won't be
> lost.  We'll shortly "git rm -rf *" in each of the branches in the
> ompi-release repo and leave a short README explaining that that branch has
> now moved to the ompi repo -- just to further accentuate that that repo is
> now closed / stale.
>
> There were a handful of PRs still open on the ompi-release repo: some were
> failing CI tests, some hadn't received reviews, etc.  Authors need to open
> new PRs on the ompi repo to get them into release branches.  I left them
> open so that they would be easy to find; authors: please close them when
> you open a new corresponding PR on the ompi repo.
>
> The ompi-all-the-branches sandbox repo has been deleted.
>
> As discussed in an email earlier today, the use of the "bot:" commands are
> no longer necessary.  You can just directly set labels, set milestones, and
> assign people to pull requests on the ompi repo (even on release
> branches).  Yay!
>
> Also, the new github "review" functionality is *required* on all PRs on
> release branches (but not on master).  We have required reviews on release
> branches for a long time; Github now enforces this requirement for us.
>
> The wiki pages about making PRs (and the bot and ...) are now out of
> date.  If someone could go update them to reflect this new arrangement, I
> would greatly appreciate it (I have already spent far too much time on all
> the infrastructure work lately) -- thank you!
>
> Long live the ompi repo!
>
> --
> Jeff Squyres
> jsquy...@cisco.com
> For corporate legal information go to: http://www.cisco.com/web/
> about/doing_business/legal/cri/
>
> ___
> devel mailing list
> devel@lists.open-mpi.org
> https://rfd.newmexicoconsortium.org/mailman/listinfo/devel
>



-- 
Josh Hursey
IBM Spectrum MPI Developer
___
devel mailing list
devel@lists.open-mpi.org
https://rfd.newmexicoconsortium.org/mailman/listinfo/devel

[OMPI devel] master broken on (at least) OpenBSD-6

2016-09-22 Thread Paul Hargrove 
When trying to test PR2107 on OpenBSD-6 I was blocked by the following
error, which is also present in 'master'.

../../../ompi/opal/util/if.c: In function 'opal_ifisloopback':
../../../ompi/opal/util/if.c:710: error: 'IFF_LOOPBACK' undeclared (first
use in this function)
../../../ompi/opal/util/if.c:710: error: (Each undeclared identifier is
reported only once
../../../ompi/opal/util/if.c:710: error: for each function it appears in.)
../../../ompi/opal/util/if.c: In function 'opal_ifgetaliases':
../../../ompi/opal/util/if.c:791: error: 'IFF_LOOPBACK' undeclared (first
use in this function)

The constant IFF_LOOPBACK is defined in net/if.h, as expected.
However, opal_config.h says:

/* #undef HAVE_NET_IF_H */


Related to that is the following output from configure:

checking net/if.h usability... no
checking net/if.h presence... yes
configure: WARNING: net/if.h: present but cannot be compiled
configure: WARNING: net/if.h: check for missing prerequisite headers?
configure: WARNING: net/if.h: see the Autoconf documentation
configure: WARNING: net/if.h: section "Present But Cannot Be Compiled"
configure: WARNING: net/if.h: proceeding with the compiler's result
configure: WARNING: ##
-- ##
configure: WARNING: ## Report this to
http://www.open-mpi.org/community/help/ ##
configure: WARNING: ##
-- ##
checking for net/if.h... no


Details from config.log:

configure:62402: checking net/if.h usability
configure:62402: gcc -std=gnu99 -c -O3 -DNDEBUG -finline-functions
-fno-strict-aliasing  conftest.c >&5
In file included from conftest.c:433:
/usr/include/net/if.h:358: error: field 'ifru_addr' has incomplete type
/usr/include/net/if.h:359: error: field 'ifru_dstaddr' has incomplete type
/usr/include/net/if.h:360: error: field 'ifru_broadaddr' has incomplete type
/usr/include/net/if.h:387: error: field 'ifrau_addr' has incomplete type
/usr/include/net/if.h:393: error: field 'ifra_dstaddr' has incomplete type
/usr/include/net/if.h:395: error: field 'ifra_mask' has incomplete type
/usr/include/net/if.h:438: error: field 'addr' has incomplete type
/usr/include/net/if.h:439: error: field 'dstaddr' has incomplete type
/usr/include/net/if.h:445: error: expected specifier-qualifier-list before
'sa_family_t'
In file included from /usr/include/net/if.h:454,
 from conftest.c:433:
/usr/include/net/if_arp.h:79: error: field 'arp_pa' has incomplete type
/usr/include/net/if_arp.h:80: error: field 'arp_ha' has incomplete type


Man page for if_nametoindex() and friends show:

 #include 
 #include 
 #include 


It looks like configure.ac is *trying* to deal with the sys/socket.h
dependency:

# Needed to work around Darwin requiring sys/socket.h for
# net/if.h
AC_CHECK_HEADERS([net/if.h], [], [],
[#include 
#if STDC_HEADERS
# include 
# include 
#else
# if HAVE_STDLIB_H
#  include 
# endif
#endif
#if HAVE_SYS_SOCKET_H
# include 
#endif
])


However, config.log suggests that the previous failure has been cached,
making this (second) test for net/if.h a no-op:

configure:62453: checking for net/if.h
configure:62453: result: no



-Paul

-- 
Paul H. Hargrove  phhargr...@lbl.gov
Computer Languages & Systems Software (CLaSS) Group
Computer Science Department   Tel: +1-510-495-2352
Lawrence Berkeley National Laboratory Fax: +1-510-486-6900
___
devel mailing list
devel@lists.open-mpi.org
https://rfd.newmexicoconsortium.org/mailman/listinfo/devel

[OMPI devel] Open MPI v2.1.0 timeline

2016-09-22 Thread Jeff Squyres (jsquyres) 
SHORT VERSION

Per Dallas discussions:

  *   We're looking to release v2.1.0 by 31 Oct
  *   Feature freeze / cutoff is 30 Sep
  *   There are "must have" items that will block the release schedule

If we really want a release by 31 Oct, there is much work to do in a short 
amount of time.

MORE DETAIL

Per our Dallas discussions 
(https://github.com/open-mpi/ompi/wiki/Meeting-2016-08 and 
https://github.com/open-mpi/ompi/wiki/Meeting-Minutes-2016-08), we are looking 
to release v2.1.0 by the end of October.

We had talked about September 30 as the feature freeze date for v2.1.0.  This 
is rapidly approaching.

According to https://github.com/open-mpi/ompi/wiki/Releasev2x, here are the 
remaining incomplete v2.1.0 "must have's":


  *   PMIx 2.0 integration (Intel, MLNX) - partially in master Issue 
#2072. Will require porting to 
the v2.x branch.
  *   Open SHMEM 1.3 compliance issue #2109 tracking multiple 
PRs
  *   mpool/rcache rewrite (LANL) - already in master
  *   HCOLL datatypes - already in master
  *   Better CMA support detection / make CMA the default in vader PR 
#1306

Other new features can be accepted to v2.1.0, but not after 30 Sep.

Additionally, there are currently 6 blocker issues: 
https://github.com/open-mpi/ompi/issues?utf8=%E2%9C%93=is%3Aissue%20is%3Aopen%20milestone%3Av2.1.0%20label%3Ablocker
 in various states (some haven't started, some are partially complete, some are 
all-but-complete).  These, too, must be fixed before release, and may delay the 
release.

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

___
devel mailing list
devel@lists.open-mpi.org
https://rfd.newmexicoconsortium.org/mailman/listinfo/devel

Re: [OMPI devel] Error in hwloc configury

2016-09-22 Thread r...@open-mpi.org 
Good job, Gilles! PR coming - this fixed the problem.

> On Sep 22, 2016, at 6:52 AM, Gilles Gouaillardet 
>  wrote:
> 
> Ralph,
> 
> if you have libevent in your CPPFLAGS and you want to use the embedded
> one, then  please use the patch below
> pmix3x looks ok
> 
> Cheers,
> 
> Gilles
> 
> diff --git a/opal/mca/event/libevent2022/configure.m4
> b/opal/mca/event/libevent2022/configure.m4
> 
> index d299b5f..8124c11 100644
> 
> --- a/opal/mca/event/libevent2022/configure.m4
> 
> +++ b/opal/mca/event/libevent2022/configure.m4
> 
> @@ -75,9 +75,9 @@ EOF
> 
># Add some stuff to CPPFLAGS so that the rest of the source
> 
># tree can be built
> 
>libevent_file=$libevent_basedir/libevent
> 
> -   CPPFLAGS="$CPPFLAGS -I$OPAL_TOP_SRCDIR/$libevent_file
> -I$OPAL_TOP_SRCDIR/$libevent_file/include"
> 
>AS_IF([test "$OPAL_TOP_BUILDDIR" != "$OPAL_TOP_SRCDIR"],
> 
> - [CPPFLAGS="$CPPFLAGS
> -I$OPAL_TOP_BUILDDIR/$libevent_file/include"])
> 
> +
> [CPPFLAGS="-I$OPAL_TOP_BUILDDIR/$libevent_file/include $CPPFLAGS"])
> 
> +   CPPFLAGS="-I$OPAL_TOP_SRCDIR/$libevent_file
> -I$OPAL_TOP_SRCDIR/$libevent_file/include $CPPFLAGS"
> 
>unset libevent_file
> 
>   ])
> 
> ])
> 
> diff --git a/opal/mca/hwloc/hwloc1113/configure.m4
> b/opal/mca/hwloc/hwloc1113/configure.m4
> 
> index 7fe3527..c1646d4 100644
> 
> --- a/opal/mca/hwloc/hwloc1113/configure.m4
> 
> +++ b/opal/mca/hwloc/hwloc1113/configure.m4
> 
> @@ -52,9 +52,9 @@ AC_DEFUN([MCA_opal_hwloc_hwloc1113_POST_CONFIG],[
> 
># Add some stuff to CPPFLAGS so that the rest of the source
> 
># tree can be built
> 
>file=$opal_hwloc_hwloc1113_basedir/hwloc
> 
> -   CPPFLAGS="$CPPFLAGS -I$OPAL_TOP_SRCDIR/$file/include"
> 
>AS_IF([test "$OPAL_TOP_BUILDDIR" != "$OPAL_TOP_SRCDIR"],
> 
> - [CPPFLAGS="$CPPFLAGS -I$OPAL_TOP_BUILDDIR/$file/include"])
> 
> + [CPPFLAGS="-I$OPAL_TOP_BUILDDIR/$file/include $CPPFLAGS"])
> 
> +   CPPFLAGS="-I$OPAL_TOP_SRCDIR/$file/include $CPPFLAGS"
> 
>unset file
> 
>   ])
> 
> OPAL_VAR_SCOPE_POP
> 
> diff --git a/opal/mca/hwloc/hwloc1113/hwloc/config/hwloc.m4
> b/opal/mca/hwloc/hwloc1113/hwloc/config/hwloc.m4
> 
> index 6807624..3f6a6fe 100644
> 
> --- a/opal/mca/hwloc/hwloc1113/hwloc/config/hwloc.m4
> 
> +++ b/opal/mca/hwloc/hwloc1113/hwloc/config/hwloc.m4
> 
> @@ -988,7 +988,7 @@ EOF])
> 
> if test "x$enable_cpuid" != "xno"; then
> 
>AC_MSG_CHECKING([for x86 cpuid])
> 
>old_CPPFLAGS="$CPPFLAGS"
> 
> -   CPPFLAGS="$CPPFLAGS -I$HWLOC_top_srcdir/include"
> 
> +   CPPFLAGS="-I$HWLOC_top_srcdir/include $CPPFLAGS"
> 
># We need hwloc_uint64_t but we can't use
> hwloc/autogen/config.h before configure ends.
> 
># So pass #include/#define manually here for now.
> 
>CPUID_CHECK_HEADERS=
> 
> 
> On Thu, Sep 22, 2016 at 10:39 PM, Gilles Gouaillardet
>  wrote:
>> Ralph,
>> 
>> do you use VPATH ?
>> 
>> can you give a try to the patch below ?
>> 
>> Cheers,
>> 
>> Gilles
>> 
>> diff --git a/opal/mca/hwloc/hwloc1113/configure.m4
>> b/opal/mca/hwloc/hwloc1113/configure.m4
>> 
>> index 7fe3527..c1646d4 100644
>> 
>> --- a/opal/mca/hwloc/hwloc1113/configure.m4
>> 
>> +++ b/opal/mca/hwloc/hwloc1113/configure.m4
>> 
>> @@ -52,9 +52,9 @@ AC_DEFUN([MCA_opal_hwloc_hwloc1113_POST_CONFIG],[
>> 
>># Add some stuff to CPPFLAGS so that the rest of the source
>> 
>># tree can be built
>> 
>>file=$opal_hwloc_hwloc1113_basedir/hwloc
>> 
>> -   CPPFLAGS="$CPPFLAGS -I$OPAL_TOP_SRCDIR/$file/include"
>> 
>>AS_IF([test "$OPAL_TOP_BUILDDIR" != "$OPAL_TOP_SRCDIR"],
>> 
>> - [CPPFLAGS="$CPPFLAGS -I$OPAL_TOP_BUILDDIR/$file/include"])
>> 
>> + [CPPFLAGS="-I$OPAL_TOP_BUILDDIR/$file/include $CPPFLAGS"])
>> 
>> +   CPPFLAGS="-I$OPAL_TOP_SRCDIR/$file/include $CPPFLAGS"
>> 
>>unset file
>> 
>>   ])
>> 
>> OPAL_VAR_SCOPE_POP
>> 
>> diff --git a/opal/mca/hwloc/hwloc1113/hwloc/config/hwloc.m4
>> b/opal/mca/hwloc/hwloc1113/hwloc/config/hwloc.m4
>> 
>> index 6807624..3f6a6fe 100644
>> 
>> --- a/opal/mca/hwloc/hwloc1113/hwloc/config/hwloc.m4
>> 
>> +++ b/opal/mca/hwloc/hwloc1113/hwloc/config/hwloc.m4
>> 
>> @@ -988,7 +988,7 @@ EOF])
>> 
>> if test "x$enable_cpuid" != "xno"; then
>> 
>>AC_MSG_CHECKING([for x86 cpuid])
>> 
>>old_CPPFLAGS="$CPPFLAGS"
>> 
>> -   CPPFLAGS="$CPPFLAGS -I$HWLOC_top_srcdir/include"
>> 
>> +   CPPFLAGS="-I$HWLOC_top_srcdir/include $CPPFLAGS"
>> 
>># We need hwloc_uint64_t but we can't use
>> hwloc/autogen/config.h before configure ends.
>> 
>># So pass #include/#define manually here for now.
>> 
>>CPUID_CHECK_HEADERS=
>> 
>> 
>> On Thu, Sep 22, 2016 at 10:13 PM, r...@open-mpi.org

Re: [OMPI devel] Error in hwloc configury

2016-09-22 Thread Gilles Gouaillardet 
Ralph,

if you have libevent in your CPPFLAGS and you want to use the embedded
one, then  please use the patch below
pmix3x looks ok

Cheers,

Gilles

diff --git a/opal/mca/event/libevent2022/configure.m4
b/opal/mca/event/libevent2022/configure.m4

index d299b5f..8124c11 100644

--- a/opal/mca/event/libevent2022/configure.m4

+++ b/opal/mca/event/libevent2022/configure.m4

@@ -75,9 +75,9 @@ EOF

# Add some stuff to CPPFLAGS so that the rest of the source

# tree can be built

libevent_file=$libevent_basedir/libevent

-   CPPFLAGS="$CPPFLAGS -I$OPAL_TOP_SRCDIR/$libevent_file
-I$OPAL_TOP_SRCDIR/$libevent_file/include"

AS_IF([test "$OPAL_TOP_BUILDDIR" != "$OPAL_TOP_SRCDIR"],

- [CPPFLAGS="$CPPFLAGS
-I$OPAL_TOP_BUILDDIR/$libevent_file/include"])

+
[CPPFLAGS="-I$OPAL_TOP_BUILDDIR/$libevent_file/include $CPPFLAGS"])

+   CPPFLAGS="-I$OPAL_TOP_SRCDIR/$libevent_file
-I$OPAL_TOP_SRCDIR/$libevent_file/include $CPPFLAGS"

unset libevent_file

   ])

 ])

diff --git a/opal/mca/hwloc/hwloc1113/configure.m4
b/opal/mca/hwloc/hwloc1113/configure.m4

index 7fe3527..c1646d4 100644

--- a/opal/mca/hwloc/hwloc1113/configure.m4

+++ b/opal/mca/hwloc/hwloc1113/configure.m4

@@ -52,9 +52,9 @@ AC_DEFUN([MCA_opal_hwloc_hwloc1113_POST_CONFIG],[

# Add some stuff to CPPFLAGS so that the rest of the source

# tree can be built

file=$opal_hwloc_hwloc1113_basedir/hwloc

-   CPPFLAGS="$CPPFLAGS -I$OPAL_TOP_SRCDIR/$file/include"

AS_IF([test "$OPAL_TOP_BUILDDIR" != "$OPAL_TOP_SRCDIR"],

- [CPPFLAGS="$CPPFLAGS -I$OPAL_TOP_BUILDDIR/$file/include"])

+ [CPPFLAGS="-I$OPAL_TOP_BUILDDIR/$file/include $CPPFLAGS"])

+   CPPFLAGS="-I$OPAL_TOP_SRCDIR/$file/include $CPPFLAGS"

unset file

   ])

 OPAL_VAR_SCOPE_POP

diff --git a/opal/mca/hwloc/hwloc1113/hwloc/config/hwloc.m4
b/opal/mca/hwloc/hwloc1113/hwloc/config/hwloc.m4

index 6807624..3f6a6fe 100644

--- a/opal/mca/hwloc/hwloc1113/hwloc/config/hwloc.m4

+++ b/opal/mca/hwloc/hwloc1113/hwloc/config/hwloc.m4

@@ -988,7 +988,7 @@ EOF])

 if test "x$enable_cpuid" != "xno"; then

AC_MSG_CHECKING([for x86 cpuid])

old_CPPFLAGS="$CPPFLAGS"

-   CPPFLAGS="$CPPFLAGS -I$HWLOC_top_srcdir/include"

+   CPPFLAGS="-I$HWLOC_top_srcdir/include $CPPFLAGS"

# We need hwloc_uint64_t but we can't use
hwloc/autogen/config.h before configure ends.

# So pass #include/#define manually here for now.

CPUID_CHECK_HEADERS=


On Thu, Sep 22, 2016 at 10:39 PM, Gilles Gouaillardet
 wrote:
> Ralph,
>
> do you use VPATH ?
>
> can you give a try to the patch below ?
>
> Cheers,
>
> Gilles
>
> diff --git a/opal/mca/hwloc/hwloc1113/configure.m4
> b/opal/mca/hwloc/hwloc1113/configure.m4
>
> index 7fe3527..c1646d4 100644
>
> --- a/opal/mca/hwloc/hwloc1113/configure.m4
>
> +++ b/opal/mca/hwloc/hwloc1113/configure.m4
>
> @@ -52,9 +52,9 @@ AC_DEFUN([MCA_opal_hwloc_hwloc1113_POST_CONFIG],[
>
> # Add some stuff to CPPFLAGS so that the rest of the source
>
> # tree can be built
>
> file=$opal_hwloc_hwloc1113_basedir/hwloc
>
> -   CPPFLAGS="$CPPFLAGS -I$OPAL_TOP_SRCDIR/$file/include"
>
> AS_IF([test "$OPAL_TOP_BUILDDIR" != "$OPAL_TOP_SRCDIR"],
>
> - [CPPFLAGS="$CPPFLAGS -I$OPAL_TOP_BUILDDIR/$file/include"])
>
> + [CPPFLAGS="-I$OPAL_TOP_BUILDDIR/$file/include $CPPFLAGS"])
>
> +   CPPFLAGS="-I$OPAL_TOP_SRCDIR/$file/include $CPPFLAGS"
>
> unset file
>
>])
>
>  OPAL_VAR_SCOPE_POP
>
> diff --git a/opal/mca/hwloc/hwloc1113/hwloc/config/hwloc.m4
> b/opal/mca/hwloc/hwloc1113/hwloc/config/hwloc.m4
>
> index 6807624..3f6a6fe 100644
>
> --- a/opal/mca/hwloc/hwloc1113/hwloc/config/hwloc.m4
>
> +++ b/opal/mca/hwloc/hwloc1113/hwloc/config/hwloc.m4
>
> @@ -988,7 +988,7 @@ EOF])
>
>  if test "x$enable_cpuid" != "xno"; then
>
> AC_MSG_CHECKING([for x86 cpuid])
>
> old_CPPFLAGS="$CPPFLAGS"
>
> -   CPPFLAGS="$CPPFLAGS -I$HWLOC_top_srcdir/include"
>
> +   CPPFLAGS="-I$HWLOC_top_srcdir/include $CPPFLAGS"
>
> # We need hwloc_uint64_t but we can't use
> hwloc/autogen/config.h before configure ends.
>
> # So pass #include/#define manually here for now.
>
> CPUID_CHECK_HEADERS=
>
>
> On Thu, Sep 22, 2016 at 10:13 PM, r...@open-mpi.org  wrote:
>> Here is the compile line:
>>
>> libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../../opal/include
>> -I../../ompi/include -I../../oshmem/include
>> -I../../opal/mca/hwloc/hwloc1113/hwloc/include/private/autogen
>> -I../../opal/mca/hwloc/hwloc1113/hwloc/include/hwloc/autogen
>> -I../../ompi/mpiext/cuda/c -I../.. -I../../orte/include
>> -I/Users/rhc/local/include
>> -I/Users/rhc/openmpi/foobar/opal/mca/hwloc/hwloc1113/hwloc/include

Re: [OMPI devel] Error in hwloc configury

2016-09-22 Thread Gilles Gouaillardet 
Ralph,

do you use VPATH ?

can you give a try to the patch below ?

Cheers,

Gilles

diff --git a/opal/mca/hwloc/hwloc1113/configure.m4
b/opal/mca/hwloc/hwloc1113/configure.m4

index 7fe3527..c1646d4 100644

--- a/opal/mca/hwloc/hwloc1113/configure.m4

+++ b/opal/mca/hwloc/hwloc1113/configure.m4

@@ -52,9 +52,9 @@ AC_DEFUN([MCA_opal_hwloc_hwloc1113_POST_CONFIG],[

# Add some stuff to CPPFLAGS so that the rest of the source

# tree can be built

file=$opal_hwloc_hwloc1113_basedir/hwloc

-   CPPFLAGS="$CPPFLAGS -I$OPAL_TOP_SRCDIR/$file/include"

AS_IF([test "$OPAL_TOP_BUILDDIR" != "$OPAL_TOP_SRCDIR"],

- [CPPFLAGS="$CPPFLAGS -I$OPAL_TOP_BUILDDIR/$file/include"])

+ [CPPFLAGS="-I$OPAL_TOP_BUILDDIR/$file/include $CPPFLAGS"])

+   CPPFLAGS="-I$OPAL_TOP_SRCDIR/$file/include $CPPFLAGS"

unset file

   ])

 OPAL_VAR_SCOPE_POP

diff --git a/opal/mca/hwloc/hwloc1113/hwloc/config/hwloc.m4
b/opal/mca/hwloc/hwloc1113/hwloc/config/hwloc.m4

index 6807624..3f6a6fe 100644

--- a/opal/mca/hwloc/hwloc1113/hwloc/config/hwloc.m4

+++ b/opal/mca/hwloc/hwloc1113/hwloc/config/hwloc.m4

@@ -988,7 +988,7 @@ EOF])

 if test "x$enable_cpuid" != "xno"; then

AC_MSG_CHECKING([for x86 cpuid])

old_CPPFLAGS="$CPPFLAGS"

-   CPPFLAGS="$CPPFLAGS -I$HWLOC_top_srcdir/include"

+   CPPFLAGS="-I$HWLOC_top_srcdir/include $CPPFLAGS"

# We need hwloc_uint64_t but we can't use
hwloc/autogen/config.h before configure ends.

# So pass #include/#define manually here for now.

CPUID_CHECK_HEADERS=


On Thu, Sep 22, 2016 at 10:13 PM, r...@open-mpi.org  wrote:
> Here is the compile line:
>
> libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../../opal/include
> -I../../ompi/include -I../../oshmem/include
> -I../../opal/mca/hwloc/hwloc1113/hwloc/include/private/autogen
> -I../../opal/mca/hwloc/hwloc1113/hwloc/include/hwloc/autogen
> -I../../ompi/mpiext/cuda/c -I../.. -I../../orte/include
> -I/Users/rhc/local/include
> -I/Users/rhc/openmpi/foobar/opal/mca/hwloc/hwloc1113/hwloc/include
> -I/Users/rhc/openmpi/foobar/opal/mca/event/libevent2022/libevent
> -I/Users/rhc/openmpi/foobar/opal/mca/event/libevent2022/libevent/include
> -L/Users/rhc/local/lib -g -Wall -Wundef -Wno-long-long -Wsign-compare
> -Wmissing-prototypes -Wstrict-prototypes -Wcomment -pedantic
> -Werror-implicit-function-declaration -finline-functions
> -fno-strict-aliasing -mcx16 -MT proc.lo -MD -MP -MF .deps/proc.Tpo -c proc.c
> -fno-common -DPIC -o .libs/proc.o
> depbase=`echo qsort.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||'`;\
> /bin/sh ../../libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H
> -I. -I../../opal/include -I../../ompi/include -I../../oshmem/include
> -I../../opal/mca/hwloc/hwloc1113/hwloc/include/private/autogen
> -I../../opal/mca/hwloc/hwloc1113/hwloc/include/hwloc/autogen
> -I../../ompi/mpiext/cuda/c   -I../.. -I../../orte/include
> -I/Users/rhc/local/include
> -I/Users/rhc/openmpi/foobar/opal/mca/hwloc/hwloc1113/hwloc/include
> -I/Users/rhc/openmpi/foobar/opal/mca/event/libevent2022/libevent
> -I/Users/rhc/openmpi/foobar/opal/mca/event/libevent2022/libevent/include
> -L/Users/rhc/local/lib -g -Wall -Wundef -Wno-long-long -Wsign-compare
> -Wmissing-prototypes -Wstrict-prototypes -Wcomment -pedantic
> -Werror-implicit-function-declaration -finline-functions
> -fno-strict-aliasing -mcx16  -MT qsort.lo -MD -MP -MF $depbase.Tpo -c -o
> qsort.lo qsort.c &&\
>
>
> It looks to me like my CPPFLAGS are stuck in the middle of the whole mess -
> I wonder if that’s the problem? I see it sandwiched in-between flags for
> different levels of hwloc redirection
>
>
> On Sep 22, 2016, at 4:40 AM, Gilles Gouaillardet
>  wrote:
>
> Ralph,
>
> Is the root cause we append our stuff to CPPFLAGS, instead of prepend ?
>
> You can retrieve the compile command line with
> make V=1
>
> If my guess is correct, does someone know the rationale for append vs
> prepend ?
>
> Cheers,
>
> Gilles
>
> r...@open-mpi.org wrote:
> Hey folks
>
> I’m encountering an issue with the way we detect external HWLOC. If I have a
> directory that includes an hwloc installation in my CPPFLAGS, then we fail
> to build, even if I don’t specify anything with regard to hwloc on my
> configure cmd line. The errors I get look like:
>
> In file included from sec_basic.c:11:0:
> ../../../../opal/include/opal_config.h:1348:0: note: this is the location of
> the previous definition
>  #define HWLOC_SYM_PREFIX opal_hwloc1113_
>  ^
> In file included from
> ../../../../opal/mca/hwloc/hwloc1113/hwloc/include/hwloc.h:53:0,
>  from ../../../../opal/mca/hwloc/hwloc1113/hwloc1113.h:24,
>  from ../../../../opal/mca/hwloc/hwloc.h:131,
>  from ../../../../opal/util/proc.h:21,
>  from ../../../../opal/mca/sec/sec.h:25,
>  from

Re: [OMPI devel] Error in hwloc configury

2016-09-22 Thread r...@open-mpi.org 
Here is the compile line:

libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../../opal/include 
-I../../ompi/include -I../../oshmem/include 
-I../../opal/mca/hwloc/hwloc1113/hwloc/include/private/autogen 
-I../../opal/mca/hwloc/hwloc1113/hwloc/include/hwloc/autogen 
-I../../ompi/mpiext/cuda/c -I../.. -I../../orte/include 
-I/Users/rhc/local/include 
-I/Users/rhc/openmpi/foobar/opal/mca/hwloc/hwloc1113/hwloc/include 
-I/Users/rhc/openmpi/foobar/opal/mca/event/libevent2022/libevent 
-I/Users/rhc/openmpi/foobar/opal/mca/event/libevent2022/libevent/include 
-L/Users/rhc/local/lib -g -Wall -Wundef -Wno-long-long -Wsign-compare 
-Wmissing-prototypes -Wstrict-prototypes -Wcomment -pedantic 
-Werror-implicit-function-declaration -finline-functions -fno-strict-aliasing 
-mcx16 -MT proc.lo -MD -MP -MF .deps/proc.Tpo -c proc.c  -fno-common -DPIC -o 
.libs/proc.o
depbase=`echo qsort.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||'`;\
/bin/sh ../../libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H 
-I. -I../../opal/include -I../../ompi/include -I../../oshmem/include 
-I../../opal/mca/hwloc/hwloc1113/hwloc/include/private/autogen 
-I../../opal/mca/hwloc/hwloc1113/hwloc/include/hwloc/autogen 
-I../../ompi/mpiext/cuda/c   -I../.. -I../../orte/include 
-I/Users/rhc/local/include  
-I/Users/rhc/openmpi/foobar/opal/mca/hwloc/hwloc1113/hwloc/include 
-I/Users/rhc/openmpi/foobar/opal/mca/event/libevent2022/libevent 
-I/Users/rhc/openmpi/foobar/opal/mca/event/libevent2022/libevent/include  
-L/Users/rhc/local/lib -g -Wall -Wundef -Wno-long-long -Wsign-compare 
-Wmissing-prototypes -Wstrict-prototypes -Wcomment -pedantic 
-Werror-implicit-function-declaration -finline-functions -fno-strict-aliasing 
-mcx16  -MT qsort.lo -MD -MP -MF $depbase.Tpo -c -o qsort.lo qsort.c &&\


It looks to me like my CPPFLAGS are stuck in the middle of the whole mess - I 
wonder if that’s the problem? I see it sandwiched in-between flags for 
different levels of hwloc redirection


> On Sep 22, 2016, at 4:40 AM, Gilles Gouaillardet 
>  wrote:
> 
> Ralph,
> 
> Is the root cause we append our stuff to CPPFLAGS, instead of prepend ?
> 
> You can retrieve the compile command line with
> make V=1
> 
> If my guess is correct, does someone know the rationale for append vs prepend 
> ?
> 
> Cheers,
> 
> Gilles
> 
> r...@open-mpi.org wrote:
> Hey folks
> 
> I’m encountering an issue with the way we detect external HWLOC. If I have a 
> directory that includes an hwloc installation in my CPPFLAGS, then we fail to 
> build, even if I don’t specify anything with regard to hwloc on my configure 
> cmd line. The errors I get look like:
> 
> In file included from sec_basic.c:11:0:
> ../../../../opal/include/opal_config.h:1348:0: note: this is the location of 
> the previous definition
>  #define HWLOC_SYM_PREFIX opal_hwloc1113_
>  ^
> In file included from 
> ../../../../opal/mca/hwloc/hwloc1113/hwloc/include/hwloc.h:53:0,
>  from ../../../../opal/mca/hwloc/hwloc1113/hwloc1113.h:24,
>  from ../../../../opal/mca/hwloc/hwloc.h:131,
>  from ../../../../opal/util/proc.h:21,
>  from ../../../../opal/mca/sec/sec.h:25,
>  from ../../../../opal/mca/sec/base/base.h:23,
>  from sec_basic.c:22:
> /Users/rhc/local/include/hwloc/autogen/config.h:200:0: warning: 
> "HWLOC_SYM_PREFIX_CAPS" redefined
>  #define HWLOC_SYM_PREFIX_CAPS HWLOC_
>  ^
> In file included from sec_basic.c:11:0:
> ../../../../opal/include/opal_config.h:1351:0: note: this is the location of 
> the previous definition
>  #define HWLOC_SYM_PREFIX_CAPS OPAL_HWLOC1113_
>  ^
> Undefined symbols for architecture x86_64:
>   "_hwloc_bitmap_alloc", referenced from:
>   import-atom in libopen-pal.dylib
>   "_hwloc_bitmap_and", referenced from:
>   import-atom in libopen-pal.dylib
>   "_hwloc_bitmap_copy", referenced from:
>   import-atom in libopen-pal.dylib
>   "_hwloc_bitmap_first", referenced from:
>   import-atom in libopen-pal.dylib
>   "_hwloc_bitmap_free", referenced from:
>   import-atom in libopen-pal.dylib
>   "_hwloc_bitmap_intersects", referenced from:
>   import-atom in libopen-pal.dylib
>   "_hwloc_bitmap_isincluded", referenced from:
> ...
> 
> Lots and lots of repetitions of the warning from many different sources, and 
> it’s clear that we somehow picked up the external header and went haywire. 
> This isn’t what we intended to have happen - we are supposed to ignore 
> external installations unless directed to use them.
> 
> Is this the expected behavior? Any way we can clean this up?
> Ralph
> 
> ___
> devel mailing list
> devel@lists.open-mpi.org
> https://rfd.newmexicoconsortium.org/mailman/listinfo/devel

___
devel mailing list
devel@lists.open-mpi.org
https://rfd.newmexicoconsortium.org/mailman/listinfo/devel

Re: [OMPI devel] Error in hwloc configury

2016-09-22 Thread Gilles Gouaillardet 
Ralph,

Is the root cause we append our stuff to CPPFLAGS, instead of prepend ?

You can retrieve the compile command line with
make V=1

If my guess is correct, does someone know the rationale for append vs prepend ?

Cheers,

Gilles

r...@open-mpi.org wrote:
>Hey folks
>
>
>I’m encountering an issue with the way we detect external HWLOC. If I have a 
>directory that includes an hwloc installation in my CPPFLAGS, then we fail to 
>build, even if I don’t specify anything with regard to hwloc on my configure 
>cmd line. The errors I get look like:
>
>
>In file included from sec_basic.c:11:0:
>
>../../../../opal/include/opal_config.h:1348:0: note: this is the location of 
>the previous definition
>
> #define HWLOC_SYM_PREFIX opal_hwloc1113_
>
> ^
>
>In file included from 
>../../../../opal/mca/hwloc/hwloc1113/hwloc/include/hwloc.h:53:0,
>
>                 from ../../../../opal/mca/hwloc/hwloc1113/hwloc1113.h:24,
>
>                 from ../../../../opal/mca/hwloc/hwloc.h:131,
>
>                 from ../../../../opal/util/proc.h:21,
>
>                 from ../../../../opal/mca/sec/sec.h:25,
>
>                 from ../../../../opal/mca/sec/base/base.h:23,
>
>                 from sec_basic.c:22:
>
>/Users/rhc/local/include/hwloc/autogen/config.h:200:0: warning: 
>"HWLOC_SYM_PREFIX_CAPS" redefined
>
> #define HWLOC_SYM_PREFIX_CAPS HWLOC_
>
> ^
>
>In file included from sec_basic.c:11:0:
>
>../../../../opal/include/opal_config.h:1351:0: note: this is the location of 
>the previous definition
>
> #define HWLOC_SYM_PREFIX_CAPS OPAL_HWLOC1113_
>
> ^
>
>Undefined symbols for architecture x86_64:
>
>  "_hwloc_bitmap_alloc", referenced from:
>
>      import-atom in libopen-pal.dylib
>
>  "_hwloc_bitmap_and", referenced from:
>
>      import-atom in libopen-pal.dylib
>
>  "_hwloc_bitmap_copy", referenced from:
>
>      import-atom in libopen-pal.dylib
>
>  "_hwloc_bitmap_first", referenced from:
>
>      import-atom in libopen-pal.dylib
>
>  "_hwloc_bitmap_free", referenced from:
>
>      import-atom in libopen-pal.dylib
>
>  "_hwloc_bitmap_intersects", referenced from:
>
>      import-atom in libopen-pal.dylib
>
>  "_hwloc_bitmap_isincluded", referenced from:
>
>...
>
>
>Lots and lots of repetitions of the warning from many different sources, and 
>it’s clear that we somehow picked up the external header and went haywire. 
>This isn’t what we intended to have happen - we are supposed to ignore 
>external installations unless directed to use them.
>
>
>Is this the expected behavior? Any way we can clean this up?
>
>Ralph
>
>
___
devel mailing list
devel@lists.open-mpi.org
https://rfd.newmexicoconsortium.org/mailman/listinfo/devel

Re: [OMPI devel] OMPI devel] RFC: Reenabling the TCP BTL over local interfaces (when specifically requested)

2016-09-22 Thread George Bosilca 
Thanks for clarifying, I now understand what your objection/suggestion was.
We all misconfigured OMPI at least once, but that allowed us to learn how
to do it right.

Instead of adding extra protections for corner-cases, maybe we should fix
our exclusivity flag so that the scenario you describe would not happen.

  George.

PS: "btl_tcp_if_exclude = ^ib0" qualifies as a honest mistake. I wouldn't
dare proposing a new MCA param to prevent this ...


On Wed, Sep 21, 2016 at 10:54 PM, Gilles Gouaillardet <
gilles.gouaillar...@gmail.com> wrote:

> ok, i was not clear
>
> by "let's consider the case where "lo" is *not* excluded via the
> btl_tcp_if_exclude MCA param" i really meant
> "let's consider the case where the value of the btl_tcp_if_exclude MCA
> param has been forced to a list of network/interfaces that do not
> contain any reference (e.g. name nor subnet) to the loopback
> interface"
> /* in a previous example, i did mpirun --mca btl_tcp_if_exclude ^ib0 */
>
> my concern is that openmpi-mca-params.conf contains
> btl_tcp_if_exclude = ^ib0
>
> then hiccups will start when Open MPI is updated, and i expect some
> complains.
> of course we can reply, doc should have been read and advices
> followed, so one cannot complain just because he has been lucky so
> far.
> or we can do things a bit differently so we do not run into this case
>
> /* if btl/self is excluded, the app will not start and it is trivial
> to append to the error message a note asking to ensure btl/self was
> not excluded.
> in this case, i do not think we have a mechanism to issue a warning
> message (e.g. "ensure lo is excluded") when hiccups occur. */
>
> Cheers,
>
> Gilles
>
> On Thu, Sep 22, 2016 at 9:54 AM, George Bosilca 
> wrote:
> > On Wednesday, September 21, 2016, Gilles Gouaillardet
> >  wrote:
> >>
> >> George,
> >>
> >> let's consider the case where "lo" is *not* excluded via the
> >> btl_tcp_if_exclude MCA param
> >> (if i understand correctly, the following is also true if "lo" is
> >> included via the btl_tcp_if_include MCA param)
> >>
> >> currently, and because of/thanks to the test that is done "deep inside"
> >> 1) on a disconnected laptop, mpirun --mca btl tcp,self ... fails with
> >> 2 tasks or more because tasks cannot reach each other
> >> 2) on a (connected) cluster, "lo" is never used and mpirun --mca btl
> >> tcp,self ... does not hang when tasks are running on two nodes or more
> >>
> >> with your proposal :
> >> 3) on a disconnected laptop, mpirun --mca btl tcp,self ... works with
> >> any number of taks, because "lo" is used by btl/tcp
> >> 4) on a (connected) cluster, "lo" is used and mpirun --mca btl
> >> tcp,self ... will very likely hang when tasks are running on two nodes
> >> or more
> >>
> >> am i right so far ?
> >
> >
> > No, you are missing the fact that thanks to our if_exclude (which
> contains
> > by default 127.0.0.0/24) we will never use lo (not even with my patch).
> > Thus, local interfaces will remain out of reach for most users, with the
> > exception of those that manually force the inclusion of lo via
> if_include.
> >
> > On a cluster where a user explicitly enable lo, there will be some
> hiccups
> > during startup. However, as Paul states we explicitly discourage people
> of
> > doing that in the README. Second, the connection over lo will eventually
> > timeout, and lo it will be dropped and all pending communications will be
> > redirected through another TCP interface.
> >
> > Cheers,
> > George.
> >
> >
> >>
> >> my concern is 4)
> >> as Paul pointed out, we can consider this is not an issue since this
> >> is a user/admin mistake, and we do not care whether this is an honest
> >> one or not. that being said, this is not very friendly since something
> >> that is working fine today will (likely) start hanging when your patch
> >> is merged.
> >>
> >> my suggestion differs since it is basically 2) and 3), which can be
> >> seen as the best of both worlds
> >>
> >> makes sense ?
> >>
> >> as a side note, there were some discussions about automatically adding
> >> the self btl,
> >> and even offering a user friendly alternative to --mca btl xxx
> >> (for example --networks shm,infiniband. today Open MPI does not
> >> provide any alternative to btl/self. also infiniband can be used via
> >> btl/openib, mtl/mxm or libfabric, which makes it painful to
> >> blacklist). i cannot remember the outcome of the discussion (if any).
> >>
> >> Cheers,
> >>
> >> Gilles
> >>
> >> On Thu, Sep 22, 2016 at 4:57 AM, George Bosilca 
> >> wrote:
> >> > Gilles,
> >> >
> >> > I don't understand how your proposal is any different than what we
> have
> >> > today. I quote "If [locality flag is set], then we could keep a hard
> >> > coded
> >> > test so 127.x.y.z address (and IPv6 equivalent) are never used (even
> if
> >> > included or not excluded) for inter node communication". We already
> have
> >> > a
> >> > hardcoded test to

[OMPI devel] Error in hwloc configury

2016-09-22 Thread r...@open-mpi.org 
Hey folks

I’m encountering an issue with the way we detect external HWLOC. If I have a 
directory that includes an hwloc installation in my CPPFLAGS, then we fail to 
build, even if I don’t specify anything with regard to hwloc on my configure 
cmd line. The errors I get look like:

In file included from sec_basic.c:11:0:
../../../../opal/include/opal_config.h:1348:0: note: this is the location of 
the previous definition
 #define HWLOC_SYM_PREFIX opal_hwloc1113_
 ^
In file included from 
../../../../opal/mca/hwloc/hwloc1113/hwloc/include/hwloc.h:53:0,
 from ../../../../opal/mca/hwloc/hwloc1113/hwloc1113.h:24,
 from ../../../../opal/mca/hwloc/hwloc.h:131,
 from ../../../../opal/util/proc.h:21,
 from ../../../../opal/mca/sec/sec.h:25,
 from ../../../../opal/mca/sec/base/base.h:23,
 from sec_basic.c:22:
/Users/rhc/local/include/hwloc/autogen/config.h:200:0: warning: 
"HWLOC_SYM_PREFIX_CAPS" redefined
 #define HWLOC_SYM_PREFIX_CAPS HWLOC_
 ^
In file included from sec_basic.c:11:0:
../../../../opal/include/opal_config.h:1351:0: note: this is the location of 
the previous definition
 #define HWLOC_SYM_PREFIX_CAPS OPAL_HWLOC1113_
 ^
Undefined symbols for architecture x86_64:
  "_hwloc_bitmap_alloc", referenced from:
  import-atom in libopen-pal.dylib
  "_hwloc_bitmap_and", referenced from:
  import-atom in libopen-pal.dylib
  "_hwloc_bitmap_copy", referenced from:
  import-atom in libopen-pal.dylib
  "_hwloc_bitmap_first", referenced from:
  import-atom in libopen-pal.dylib
  "_hwloc_bitmap_free", referenced from:
  import-atom in libopen-pal.dylib
  "_hwloc_bitmap_intersects", referenced from:
  import-atom in libopen-pal.dylib
  "_hwloc_bitmap_isincluded", referenced from:
...

Lots and lots of repetitions of the warning from many different sources, and 
it’s clear that we somehow picked up the external header and went haywire. This 
isn’t what we intended to have happen - we are supposed to ignore external 
installations unless directed to use them.

Is this the expected behavior? Any way we can clean this up?
Ralph

___
devel mailing list
devel@lists.open-mpi.org
https://rfd.newmexicoconsortium.org/mailman/listinfo/devel

Re: [OMPI devel] [OMPI commits] Git: open-mpi/ompi branch master updated. v2.x-dev-2911-gc7bf9a0

2016-09-22 Thread r...@open-mpi.org 
Hey Gilles

This fix doesn’t look right to me. 

> +/* we read something - better get more */
> +num_chars_read += rc;
> +orted_uri = realloc((void*)orted_uri, buffer_length+chunk);
> +memset(_uri[buffer_length], 0, chunk);
> +buffer_length += chunk;
>}

Just because you read “something”, it doesn’t mean that you have to realloc the 
buffer. You might have read only a small piece, not an entire “chunk”.

What you need to do is to see if the buffer has been filled, and only read each 
time up to the remaining number of characters available in the buffer. If the 
buffer has been filled (or if you want to optimize, if the remaining space 
falls under some minimum limit), then you realloc another ORTE_URI_MSG_LNGTH 
block.


> On Sep 21, 2016, at 10:25 PM, git...@open-mpi.org wrote:
> 
> This is an automated email from the git hooks/post-receive script. It was
> generated because a ref change was pushed to the repository containing
> the project "open-mpi/ompi".
> 
> The branch, master has been updated
>  via  c7bf9a0ec9940d6fe0ff6da5212fc881de73cf21 (commit)
> from  e1d89a4dcf5feeaf978e6806b08d609ecfb9889a (commit)
> 
> Those revisions listed above that are new to this repository have
> not appeared on any other notification email; so we list those
> revisions in full, below.
> 
> - Log -
> https://github.com/open-mpi/ompi/commit/c7bf9a0ec9940d6fe0ff6da5212fc881de73cf21
> 
> commit c7bf9a0ec9940d6fe0ff6da5212fc881de73cf21
> Author: Gilles Gouaillardet 
> Date:   Thu Sep 22 13:18:54 2016 +0900
> 
>   ess/singleton: fix read on the pipe to spawn'ed orted
> 
>   and close the pipe on both ends when it is no more needed
> 
> diff --git a/orte/mca/ess/singleton/ess_singleton_module.c 
> b/orte/mca/ess/singleton/ess_singleton_module.c
> index 571d453..55c7985 100644
> --- a/orte/mca/ess/singleton/ess_singleton_module.c
> +++ b/orte/mca/ess/singleton/ess_singleton_module.c
> @@ -571,20 +571,20 @@ static int fork_hnp(void)
>orted_uri = (char*)malloc(buffer_length);
>memset(orted_uri, 0, buffer_length);
> 
> -while (chunk == (rc = read(p[0], _uri[num_chars_read], 
> chunk))) {
> +while (0 != (rc = read(p[0], _uri[num_chars_read], chunk))) {
>if (rc < 0 && (EAGAIN == errno || EINTR == errno)) {
>continue;
> -} else {
> -num_chars_read = 0;
> +} else if (rc < 0) {
> +num_chars_read = -1;
>break;
>}
> -/* we read an entire buffer - better get more */
> -num_chars_read += chunk;
> -orted_uri = realloc((void*)orted_uri, 
> buffer_length+ORTE_URI_MSG_LGTH);
> -memset(_uri[buffer_length], 0, ORTE_URI_MSG_LGTH);
> -buffer_length += ORTE_URI_MSG_LGTH;
> +/* we read something - better get more */
> +num_chars_read += rc;
> +orted_uri = realloc((void*)orted_uri, buffer_length+chunk);
> +memset(_uri[buffer_length], 0, chunk);
> +buffer_length += chunk;
>}
> -num_chars_read += rc;
> +close(p[0]);
> 
>if (num_chars_read <= 0) {
>/* we didn't get anything back - this is bad */
> diff --git a/orte/orted/orted_main.c b/orte/orted/orted_main.c
> index 3c7bc63..0e7c318 100644
> --- a/orte/orted/orted_main.c
> +++ b/orte/orted/orted_main.c
> @@ -628,6 +628,7 @@ int orte_daemon(int argc, char *argv[])
> 
>/* cleanup */
>free(tmp);
> +close(orted_globals.uri_pipe);
> 
>/* since a singleton spawned us, we need to harvest
> * any MCA params from the local environment so
> 
> 
> ---
> 
> Summary of changes:
> orte/mca/ess/singleton/ess_singleton_module.c |   18 +-
> orte/orted/orted_main.c   |1 +
> 2 files changed, 10 insertions(+), 9 deletions(-)
> 
> 
> hooks/post-receive
> -- 
> open-mpi/ompi
> ___
> ompi-commits mailing list
> ompi-comm...@lists.open-mpi.org
> https://rfd.newmexicoconsortium.org/mailman/listinfo/ompi-commits

___
devel mailing list
devel@lists.open-mpi.org
https://rfd.newmexicoconsortium.org/mailman/listinfo/devel