[hwloc-devel] Create success (hwloc r1.7.1rc1r5612)

2013-05-09 Thread MPI Team 
Creating nightly hwloc snapshot SVN tarball was a success.

Snapshot:   hwloc 1.7.1rc1r5612
Start time: Thu May  9 21:05:32 EDT 2013
End time:   Thu May  9 21:09:46 EDT 2013

Your friendly daemon,
Cyrador

[hwloc-devel] Create success (hwloc r1.8a1r5611)

2013-05-09 Thread MPI Team 
Creating nightly hwloc snapshot SVN tarball was a success.

Snapshot:   hwloc 1.8a1r5611
Start time: Thu May  9 21:01:01 EDT 2013
End time:   Thu May  9 21:05:32 EDT 2013

Your friendly daemon,
Cyrador

Re: [hwloc-devel] [hwloc-svn] svn:hwloc r5606 - trunk

2013-05-09 Thread Brice Goglin 
It was already fixed by the revert, sorry I forgot to make that clear.

We only use C++ to build a *C* file with g++. We don't have actual C++
code. Looks like CXX gets initialized properly, even when I comment out
our AC_PROC_CXX in configure.ac and the following code in hwloc_internal.m4:

AC_MSG_CHECKING(if CXX works)
AC_LANG_PUSH([C++])
AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[
#include 
using namespace std;
int foo(void) {
  cout << "test" << endl;
  return 0;
}
]])], [hwloc_have_cxx=yes], [hwloc_have_cxx=no])
AC_LANG_POP([C++])
AC_MSG_RESULT([$hwloc_have_cxx])



If we remove the above and use LT_LANG(C++), what do you use instead of
"if HWLOC_HAVE_CXX" in doc/Makefile.am

Brice



Le 09/05/2013 14:57, Jeff Squyres (jsquyres) a écrit :
> Does this patch fix it?  It's not clear to me from the LT docs whether you're 
> supposed to call LT_LANG multiple times or LT_LANG with multiple languages, 
> but this patch below seems to run the libtool C++ configury:
>
> Index: configure.ac
> ===
> --- configure.ac  (revision 5609)
> +++ configure.ac  (working copy)
> @@ -168,6 +168,7 @@
>  AM_DISABLE_STATIC
>  AM_PROG_LIBTOOL([dlopen win32-dll])
>  LT_LANG([C])
> +LT_LANG([C++])
>  LT_CONFIG_LTDL_DIR([src/libltdl])
>  LTDL_INIT([recursive convenience])
>  AC_CONFIG_FILES([src/libltdl/Makefile])
>
> (I couldn't generate the make check failure on my Mac with or without the 
> additional LT_LANG, so I can't confirm if this is the correct fix or not)
>
>
> On May 8, 2013, at 2:28 AM, Brice Goglin  wrote:
>
>> We actually used C++ during make check (we test the C++ build of
>> doc/hwloc-hello.c)
>> (got a build failure report from https://ci.inria.fr/hwloc/)
>>
>> Brice
>>
>>
>>
>> Le 08/05/2013 02:27, svn-commit-mai...@open-mpi.org a écrit :
>>> Author: jsquyres (Jeff Squyres)
>>> Date: 2013-05-07 20:27:25 EDT (Tue, 07 May 2013)
>>> New Revision: 5606
>>> URL: https://svn.open-mpi.org/trac/hwloc/changeset/5606
>>>
>>> Log:
>>> Revert r5604 -- it's redundant with LT_LANG([C]).
>>>
>>> Text files modified: 
>>>   trunk/configure.ac | 4 
>>>   1 files changed, 0 insertions(+), 4 deletions(-)
>>>
>>> Modified: trunk/configure.ac
>>> ==
>>> --- trunk/configure.ac  Tue May  7 20:18:05 2013(r5605)
>>> +++ trunk/configure.ac  2013-05-07 20:27:25 EDT (Tue, 07 May 2013)  
>>> (r5606)
>>> @@ -166,10 +166,6 @@
>>> # Compiler support -- we don't need that stuff.
>>> AM_ENABLE_SHARED
>>> AM_DISABLE_STATIC
>>> -# Tell libtool that we don't need Fortran or C++ support.
>>> -FC=no
>>> -F77=no
>>> -CXX=no
>>> AM_PROG_LIBTOOL([dlopen win32-dll])
>>> LT_LANG([C])
>>> LT_CONFIG_LTDL_DIR([src/libltdl])
>>> ___
>>> hwloc-svn mailing list
>>> hwloc-...@open-mpi.org
>>> http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-svn
>> ___
>> hwloc-devel mailing list
>> hwloc-de...@open-mpi.org
>> http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-devel
>

Re: [hwloc-devel] hwloc embedding vs libltdl

2013-05-09 Thread Jeff Squyres (jsquyres) 
On May 9, 2013, at 8:55 AM, Brice Goglin  wrote:

> +Although hwloc plugins may be used in embedded mode, the embedder
> +project will have to manually setup libltdl in its build system so
> +that hwloc can load its plugins.
> +Also, embedders should avoid using their own plugins and hwloc plugins
> +simultaneously because of possible issues with public and private
> +namespaces when using libltdl.
> +The embedder project is strongly advised not to use libltdl.

Tweaked:

Although hwloc dynamic shared object plugins may be used in embedded mode, the 
embedder project will have to manually setup libltdl in its build system so
that hwloc can load its plugins at run time.  Also, embedders should be aware 
of complications that can arise due to public and private linker namespaces 
(e.g., if the embedded project is loaded into a private namespace and then 
hwloc tries to dynamically load its plugins, such loading may fail since the 
hwloc plugins can't find the hwloc symbols they need).  The embedder project is 
*strongly* advised not to use hwloc's dynamically loading plugins / libltdl 
capability.

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

Re: [hwloc-devel] [hwloc-svn] svn:hwloc r5606 - trunk

2013-05-09 Thread Jeff Squyres (jsquyres) 
Does this patch fix it?  It's not clear to me from the LT docs whether you're 
supposed to call LT_LANG multiple times or LT_LANG with multiple languages, but 
this patch below seems to run the libtool C++ configury:

Index: configure.ac
===
--- configure.ac(revision 5609)
+++ configure.ac(working copy)
@@ -168,6 +168,7 @@
 AM_DISABLE_STATIC
 AM_PROG_LIBTOOL([dlopen win32-dll])
 LT_LANG([C])
+LT_LANG([C++])
 LT_CONFIG_LTDL_DIR([src/libltdl])
 LTDL_INIT([recursive convenience])
 AC_CONFIG_FILES([src/libltdl/Makefile])

(I couldn't generate the make check failure on my Mac with or without the 
additional LT_LANG, so I can't confirm if this is the correct fix or not)


On May 8, 2013, at 2:28 AM, Brice Goglin  wrote:

> We actually used C++ during make check (we test the C++ build of
> doc/hwloc-hello.c)
> (got a build failure report from https://ci.inria.fr/hwloc/)
> 
> Brice
> 
> 
> 
> Le 08/05/2013 02:27, svn-commit-mai...@open-mpi.org a écrit :
>> Author: jsquyres (Jeff Squyres)
>> Date: 2013-05-07 20:27:25 EDT (Tue, 07 May 2013)
>> New Revision: 5606
>> URL: https://svn.open-mpi.org/trac/hwloc/changeset/5606
>> 
>> Log:
>> Revert r5604 -- it's redundant with LT_LANG([C]).
>> 
>> Text files modified: 
>>   trunk/configure.ac | 4 
>>   1 files changed, 0 insertions(+), 4 deletions(-)
>> 
>> Modified: trunk/configure.ac
>> ==
>> --- trunk/configure.ac   Tue May  7 20:18:05 2013(r5605)
>> +++ trunk/configure.ac   2013-05-07 20:27:25 EDT (Tue, 07 May 2013)  
>> (r5606)
>> @@ -166,10 +166,6 @@
>> # Compiler support -- we don't need that stuff.
>> AM_ENABLE_SHARED
>> AM_DISABLE_STATIC
>> -# Tell libtool that we don't need Fortran or C++ support.
>> -FC=no
>> -F77=no
>> -CXX=no
>> AM_PROG_LIBTOOL([dlopen win32-dll])
>> LT_LANG([C])
>> LT_CONFIG_LTDL_DIR([src/libltdl])
>> ___
>> hwloc-svn mailing list
>> hwloc-...@open-mpi.org
>> http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-svn
> 
> ___
> hwloc-devel mailing list
> hwloc-de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-devel


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

Re: [hwloc-devel] hwloc embedding vs libltdl

2013-05-09 Thread Brice Goglin 
Le 09/05/2013 12:43, Jeff Squyres (jsquyres) a écrit :
> On May 8, 2013, at 4:16 PM, Brice Goglin  wrote:
>
>> But this issue is only in the embedders (OMPI), not in the embeddee
>> (hwloc), right?
> Yes.
>
>> I can get plugins to work in tests/embedded by adding 2 lines to its
>> configure.ac (see the attached patch, which also removes your error
>> message and creates a shared lib containing libhwloc_embedded).
>>
>> In short, I don't really see what risk we would be taking on the hwloc
>> side if we keep embedding+plugins possible (and still don't enable
>> plugins by default).
> Ok.  It's probably worth documenting, though.  In the OMPI case, for example, 
> OMPI cannot be opened in a private namespace (e.g., as a python plugin) and 
> then have hwloc also opened in a private namespace; hwloc must be opened in a 
> public namespace.  This has caused unhappiness in certain cases where 
> upper-layer application authors were trying to open all plugins in private 
> namespaces but couldn't.  The same will be true with hwloc: those who embed 
> hwloc should be *strongly advised* to not use libltdl (even though it's not 
> the default) because of the private/public namespace issue.
>

Something like this?

--- a/doc/hwloc.doxy
+++ b/doc/hwloc.doxy
@@ -2147,6 +2147,9 @@ is registered to the hwloc core.
 Components are then only enabled if the topology configuration
 requests it, as explained in the previous sections.

+Also note that plugins should carefully be enabled and used when
+embedding hwloc in another project, see \ref embed for details.
+
 \section plugins_adding Adding new discovery components and plugins

 The types and functions cited below are declared in the hwloc/plugins.h header.
@@ -2338,6 +2341,14 @@ you can directly integrate hwloc's m4 configure macro 
into your
 configure script.  You can then invoke hwloc's configuration tests and
 build setup by calling an m4 macro (see below).

+Although hwloc plugins may be used in embedded mode, the embedder
+project will have to manually setup libltdl in its build system so
+that hwloc can load its plugins.
+Also, embedders should avoid using their own plugins and hwloc plugins
+simultaneously because of possible issues with public and private
+namespaces when using libltdl.
+The embedder project is strongly advised not to use libltdl.
+
 \section embedding_m4 Using hwloc's M4 Embedding Capabilities

 Every project is different, and there are many different ways of



Brice

Re: [hwloc-devel] hwloc embedding vs libltdl

2013-05-09 Thread Jeff Squyres (jsquyres) 
On May 8, 2013, at 4:16 PM, Brice Goglin  wrote:

> But this issue is only in the embedders (OMPI), not in the embeddee
> (hwloc), right?

Yes.

> I can get plugins to work in tests/embedded by adding 2 lines to its
> configure.ac (see the attached patch, which also removes your error
> message and creates a shared lib containing libhwloc_embedded).
> 
> In short, I don't really see what risk we would be taking on the hwloc
> side if we keep embedding+plugins possible (and still don't enable
> plugins by default).

Ok.  It's probably worth documenting, though.  In the OMPI case, for example, 
OMPI cannot be opened in a private namespace (e.g., as a python plugin) and 
then have hwloc also opened in a private namespace; hwloc must be opened in a 
public namespace.  This has caused unhappiness in certain cases where 
upper-layer application authors were trying to open all plugins in private 
namespaces but couldn't.  The same will be true with hwloc: those who embed 
hwloc should be *strongly advised* to not use libltdl (even though it's not the 
default) because of the private/public namespace issue.

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

Re: [hwloc-devel] Minor issue with the man page

2013-05-09 Thread Brice Goglin 
Samuel fixed it a couple weeks ago (Debian packaging tools complained
like rpmlint).
Thanks
Brice



Le 09/05/2013 09:47, Jiri Hladky a écrit :
> Hi Brice,
>
> rpmlint reports a minor typo in the man page for hwloc 1.7
>
>
> $rpmlint -i /home/jhladky/rpmbuild/RPMS/x86_64/hwloc-1.7-0.fc18.x86_64.rpm
> hwloc.x86_64: W: manual-page-warning
> /usr/share/man/man1/hwloc-info.1.gz 151: warning: macro `.' not defined
> This man page may contain problems that can cause it not to be
> formatted as
> intended.
>
>
>  $ zcat hwloc-info.1.gz | sed -ne 151p
> ..\" **
>
> There's one extra "." at the beginning of that line.
>
> Patch file is attached.
>
> Thanks
> Jirka
>
>