Re: [OMPI users] Issue with QLogic IBA7322 QDR InfiniBand HCA

[Fabricio Cannini]

Em 31-03-2014 23:06, Fabricio Cannini escreveu:


Problem solved. Rocks wasn't correctly generating '/etc/hosts' when the 
node was installed.


[ ]'s

Re: [OMPI users] usNIC point-to-point messaging module

[Dave Goodell (dgoodell)]

On Apr 1, 2014, at 12:13 PM, Filippo Spiga  wrote:

> Dear Ralph, Dear Jeff,
> 
> I've just recompiled the latest Open MPI 1.8. I added 
> "--enable-mca-no-build=btl-usnic" to configure but the message still appear. 
> Here the output of "--mca btl_base_verbose 100" (trunked immediately after 
> the application starts)

Jeff's on vacation, so I'll see if I can help here.

Try deleting all the files in "$PREFIX/lib/openmpi/", where "$PREFIX" is the 
value you passed to configure with "--prefix=".  If you did not pass a value, 
then it is "/usr/local".  Then reinstall (with "make install" in the OMPI build 
tree).

What I think is happening is that you still have an "mca_btl_usnic.so" file 
leftover from the last time you installed OMPI (before passing 
"--enable-mca-no-build=btl-usnic").  So OMPI is using this shared library and 
you get exactly the same problem.

-Dave

Re: [hwloc-users] [hwloc-announce] Hardware locality (hwloc) v1.9 released

[Jiri Hladky]

Hi Brice,

thanks for pointing this out! Using the plugins is the way to go.

Jirka


On Tue, Apr 1, 2014 at 12:58 PM, Brice Goglin  wrote:

>  That's exactely why we have plugin support. You can pass
> --enable-plugins so that all plugin-able backends are built as separate
> hwloc_foo.so files that are used only when available/loaded at runtime.
> Then you can put them in different packages and hwloc will only load the
> available ones.
>
> For instance, if libxnvctrl is the only lib that you don't want libhwloc
> to depends against, you put hwloc_gl.so in a separate package (you can even
> tell hwloc to build only gl as a plugin with --enable-plugins=gl).
>
> On Debian, the libhwloc package "recommends" libhwloc-plugins ("heavy"
> external dependencies: libxml, pci and libxml) and "suggests"
> libhwloc-contrib-plugins (non-free external dependencies: cuda, gl) and
> people are free to install what they really want. If they don't install any
> plugin package, they still get support for all operating systems, the
> Linux-specific PCI backend, the x86-specific backend and the "minimalistic"
> XML backend. Not too bad :)
>
> Another solution could be to build and distribute all plugins in the main
> hwloc package but don't have it depend on the plugin dependencies. hwloc
> tries to load all plugins, but it fails when dependene libraries are
> missing. So the CUDA plugin is only loaded if libcuda is installed. Can be
> convenient, but some distros won't let you do that.
>
> Beware that there's an ABI version number for plugins. It may change in
> the future.
>
> Brice
>
>
>
>
>
>
> Le 01/04/2014 12:23, Jiri Hladky a écrit :
>
> Hi Brice,
>
>  I'm sorry for the double report. Now when you wrote it I remember that I
> have reported it:-)
>
>  Thanks for fixing the man page.
>
>  I have one more question: RHEL has splitted hwloc into 2 subpackages
> * hwloc
> * hwloc-gui (it contains merely lstopo)
>
>  The former one does not need any X11 dependencies.
>
>  I have now tried to do the same for Fedora but it's not so easy. On
> Fedora I build the package with libXNVCtrl but libXNVCtrl needs libX11. So
> even CLI tools need libX11:
>
>  ldd lstopo-no-graphics
> linux-vdso.so.1 =>  (0x7fffbf1cb000)
> libhwloc.so.5 => /dev/shm/usr/lib/libhwloc.so.5
> (0x7f7a5277c000)
> libnuma.so.1 => /lib64/libnuma.so.1 (0x003c06a0)
> libpciaccess.so.0 => /lib64/libpciaccess.so.0 (0x003c05e0)
> libXNVCtrl.so.0 => /lib64/libXNVCtrl.so.0 (0x7f7a52545000)
> libXext.so.6 => /lib64/libXext.so.6 (0x003c07a0)
> libX11.so.6 => /lib64/libX11.so.6 (0x003c0760)
>
>  Is there any way around? (On RHEL it's easy. RHEL does not provide
> libXNVCtrl at all so the package is built without it.
> Then lstopo-no-graphics does not depend on libX11)
>
>  I currently see two options:
> A) Accept the fact that lstopo-no-graphics depends on X11. The number of
> dependencies for lstopo (from hwloc-gui package) is still much lower
> compared to  lstopo-no-graphics
> B) Compile it without libXNVCtrl but it will reduce the functionality.
>
>  Is there any 3rd option? I guess not. It seems like A) is the best
> choice for Fedora.
>
>  Any ideas on that?
>
>  Thanks!
> Jirka
>
>
>
>
> On Tue, Apr 1, 2014 at 10:54 AM, Brice Goglin wrote:
>
>> Le 01/04/2014 10:43, Jiri Hladky a écrit :
>> > Hi Brice,
>> >
>> > I see some compiler warnings when building rpm package for Fedora:
>> >
>> > topology-windows.c: In function 'hwloc_win_get_VirtualAllocExNumaProc':
>> > topology-windows.c:338:30: warning: assignment from incompatible
>> > pointer type [enabled by default]
>> > topology-windows.c:343:28: warning: assignment from incompatible
>> > pointer type [enabled by default]
>> > topology-windows.c: In function 'hwloc_look_windows':
>> > topology-windows.c:500:36: warning: assignment from incompatible
>> > pointer type [enabled by default]
>> > topology-windows.c:501:38: warning: assignment from incompatible
>> > pointer type [enabled by default]
>> >
>>
>>  You already reported those on February 13th and we replied that they are
>> harmless :)
>>
>> Moreover, these warnings come from make check under tests/ports when
>> verifying that the Windows backend builds fine using "emulated" Windows
>> headers under Linux. Something that for sure cannot be perfect. If you
>> have a way to ignore make check warnings, at least under tests/ports,
>> that'd be good.
>>
>>
>> > hwloc_backends.c: In function 'main':
>> > hwloc_backends.c:42:10: warning: ignoring return value of 'mkstemp',
>> > declared with attribute warn_unused_result [-Wunused-result]
>>
>>  Another warning from make check. We mostly don't care, I'll see if I can
>> fix it.
>>
>> I am fixing the manpage problem and backporting it.
>>
>> thanks!
>> Brice
>>
>> ___
>> hwloc-users mailing list
>> hwloc-us...@open-mpi.org
>> 

Re: [OMPI users] usNIC point-to-point messaging module

[Filippo Spiga]

Dear Ralph, Dear Jeff,

I've just recompiled the latest Open MPI 1.8. I added 
"--enable-mca-no-build=btl-usnic" to configure but the message still appear. 
Here the output of "--mca btl_base_verbose 100" (trunked immediately after the 
application starts)


srun: cluster configuration lacks support for cpu binding
[tesla88:26769] mca: base: components_register: registering btl components
[tesla88:26769] mca: base: components_register: found loaded component openib
[tesla88:26768] mca: base: components_register: registering btl components
[tesla88:26768] mca: base: components_register: found loaded component openib
[tesla88:26768] mca: base: components_register: component openib register 
function successful
[tesla88:26769] mca: base: components_register: component openib register 
function successful
[tesla88:26769] mca: base: components_register: found loaded component self
[tesla88:26768] mca: base: components_register: found loaded component self
[tesla88:26769] mca: base: components_register: component self register 
function successful
[tesla88:26768] mca: base: components_register: component self register 
function successful
[tesla88:26769] mca: base: components_register: found loaded component sm
[tesla88:26768] mca: base: components_register: found loaded component sm
[tesla88:26769] mca: base: components_register: component sm register function 
successful
[tesla88:26768] mca: base: components_register: component sm register function 
successful
[tesla88:26769] mca: base: components_register: found loaded component tcp
[tesla88:26768] mca: base: components_register: found loaded component tcp
[tesla88:26769] mca: base: components_register: component tcp register function 
successful
[tesla88:26768] mca: base: components_register: component tcp register function 
successful
[tesla88:26769] mca: base: components_register: found loaded component usnic
[tesla88:26768] mca: base: components_register: found loaded component usnic
[tesla88:26769] mca: base: components_register: component usnic register 
function successful
[tesla88:26768] mca: base: components_register: component usnic register 
function successful
[tesla88:26769] mca: base: components_register: found loaded component vader
[tesla88:26768] mca: base: components_register: found loaded component vader
[tesla88:26769] mca: base: components_register: component vader register 
function successful
[tesla88:26769] mca: base: components_open: opening btl components
[tesla88:26769] mca: base: components_open: found loaded component openib
[tesla88:26769] mca: base: components_open: component openib open function 
successful
[tesla88:26769] mca: base: components_open: found loaded component self
[tesla88:26768] mca: base: components_register: component vader register 
function successful
[tesla88:26769] mca: base: components_open: component self open function 
successful
[tesla88:26769] mca: base: components_open: found loaded component sm
[tesla88:26769] mca: base: components_open: component sm open function 
successful
[tesla88:26769] mca: base: components_open: found loaded component tcp
[tesla88:26768] mca: base: components_open: opening btl components
[tesla88:26768] mca: base: components_open: found loaded component openib
[tesla88:26768] mca: base: components_open: component openib open function 
successful
[tesla88:26768] mca: base: components_open: found loaded component self
[tesla88:26768] mca: base: components_open: component self open function 
successful
[tesla88:26768] mca: base: components_open: found loaded component sm
[tesla88:26768] mca: base: components_open: component sm open function 
successful
[tesla88:26768] mca: base: components_open: found loaded component tcp
[tesla88:26769] mca: base: components_open: component tcp open function 
successful
[tesla88:26769] mca: base: components_open: found loaded component usnic
[tesla88:26769] mca: base: components_open: component usnic open function 
successful
[tesla88:26769] mca: base: components_open: found loaded component vader
[tesla88:26769] mca: base: components_open: component vader open function 
successful
[tesla89:45456] mca: base: components_register: registering btl components
[tesla89:45456] mca: base: components_register: found loaded component openib
[tesla88:26768] mca: base: components_open: component tcp open function 
successful
[tesla88:26768] mca: base: components_open: found loaded component usnic
[tesla88:26768] mca: base: components_open: component usnic open function 
successful
[tesla88:26768] mca: base: components_open: found loaded component vader
[tesla88:26768] mca: base: components_open: component vader open function 
successful
[tesla89:45455] mca: base: components_register: registering btl components
[tesla89:45455] mca: base: components_register: found loaded component openib
[tesla89:45456] mca: base: components_register: component openib register 
function successful
[tesla89:45456] mca: base: components_register: found loaded component self

Re: [OMPI users] Problem building OpenMPI 1.8 on RHEL6

[Dave Goodell (dgoodell)]

On Apr 1, 2014, at 10:26 AM, "Blosch, Edwin L"  wrote:

> I am getting some errors building 1.8 on RHEL6.  I tried autoreconf as 
> suggested, but it failed for the same reason.  Is there a minimum version of 
> m4 required that is newer than that provided by RHEL6?

Don't run "autoreconf" by hand, make sure to run the "./autogen.sh" script that 
is packaged with OMPI.  It will also check your versions and warn you if they 
are out of date.

Do you need to build OMPI from the SVN source?  Or would a (pre-autogen'ed) 
release tarball work for you?

-Dave

Re: [OMPI users] Problem building OpenMPI 1.8 on RHEL6

[Ralph Castain]

Hmmm...indeed, it looks like the default versions may be out-of-date. Here is a 
table showing the required rev levels:

http://www.open-mpi.org/svn/building.php


On Apr 1, 2014, at 8:26 AM, Blosch, Edwin L  wrote:

> I am getting some errors building 1.8 on RHEL6.  I tried autoreconf as 
> suggested, but it failed for the same reason.  Is there a minimum version of 
> m4 required that is newer than that provided by RHEL6?
>  
> Thanks
>  
> aclocal.m4:16: warning: this file was generated for autoconf 2.69.
> You have another version of autoconf.  It may work, but is not guaranteed to.
> If you have problems, you may need to regenerate the build system entirely.
> To do so, use the procedure documented by the package, typically 'autoreconf'.
> configure.ac:40: error: m4_defn: undefined macro: _m4_divert_diversion
> configure.ac:40: the top level
> autom4te: /usr/bin/m4 failed with exit status: 1
>  
> [bloscel@head openmpi]$ autoreconf
> configure.ac:40: error: m4_defn: undefined macro: _m4_divert_diversion
> configure.ac:40: the top level
> autom4te: /usr/bin/m4 failed with exit status: 1
> aclocal: autom4te failed with exit status: 1
> autoreconf: aclocal failed with exit status: 1
> ___
> users mailing list
> us...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/users

[OMPI users] Problem building OpenMPI 1.8 on RHEL6

[Blosch, Edwin L]

I am getting some errors building 1.8 on RHEL6.  I tried autoreconf as 
suggested, but it failed for the same reason.  Is there a minimum version of m4 
required that is newer than that provided by RHEL6?

Thanks

aclocal.m4:16: warning: this file was generated for autoconf 2.69.
You have another version of autoconf.  It may work, but is not guaranteed to.
If you have problems, you may need to regenerate the build system entirely.
To do so, use the procedure documented by the package, typically 'autoreconf'.
configure.ac:40: error: m4_defn: undefined macro: _m4_divert_diversion
configure.ac:40: the top level
autom4te: /usr/bin/m4 failed with exit status: 1

[bloscel@head openmpi]$ autoreconf
configure.ac:40: error: m4_defn: undefined macro: _m4_divert_diversion
configure.ac:40: the top level
autom4te: /usr/bin/m4 failed with exit status: 1
aclocal: autom4te failed with exit status: 1
autoreconf: aclocal failed with exit status: 1

Re: [hwloc-users] misleading cache size on AMD Opteron 6348?

[Yury Vorobyov]

Current BIOS version could be improperly detecting CPUs, which engineering
samples of 6348 (all characteristics are same).


On Tue, Apr 1, 2014 at 6:59 PM, Yury Vorobyov  wrote:

> The BIOS has latest version. If I should check some BIOS information, I
> have access to hardware. Tell me what variables from SMBIOS you want to see?
>
>
> On Fri, Jan 31, 2014 at 1:07 PM, Brice Goglin wrote:
>
>>  Hello,
>>
>> Your BIOS reports invalid L3 cache information. On these processors, the
>> L3 is shared by 6 cores, it covers 6 cores of an entire half-socket NUMA
>> node. But the BIOS says that some L3 are shared between 4 cores, others by
>> 6 cores. And worse it says that some L3 is shared by some cores from a NUMA
>> node and others from another NUMA nodes, which causes the error message
>> (and these L3 cannot be inserted in the topology).
>>
>> I see "AMD Eng Sample, ZS268145TCG54_32/26/20_2/16" in the processor
>> type, so it might explain why your BIOS is somehow experimental. See if you
>> can upgrade it.
>>
>> Also make sure your kernel isn't too old in case it misses L3 info for
>> these processors. At least 3.3 should be OK iirc.
>>
>> NUMA node sharing info:
>> $ cat sys/devices/system/node/node*/cpumap
>> ,003f
>> ,0fc0
>> ,0003f000
>> ,00fc
>> $ cat sys/devices/system/cpu/cpu{?,??}/cache/index3/shared_cpu_map
>> ,000f << wrong, should be 003f
>> ,000f << wrong, should be 003f
>> ,000f << wrong, should be 003f
>> ,000f << wrong, should be 003f
>> ,03f0 <> ,03f0 <> ,03f0 <> ,03f0 <> ,03f0 <> ,03f0 <> ,0c00 <> ,0c00 <> ,3000 <> ,3000 <> ,000fc000 <> ,000fc000 <> ,000fc000 <> ,000fc000 <> ,000fc000 <> ,000fc000 <> ,00f0 <> ,00f0 <> ,00f0 <> ,00f0 <>
>> Brice
>>
>>
>>
>> Le 31/01/2014 03:46, Yury Vorobyov a écrit :
>>
>>  I have got error about "intersecting caches".
>>
>>  Info from hwloc in attachments.
>>
>>  I never got this before. I use "live" builds of OpenMPI directly from
>> repo.
>>
>>
>> ___
>> hwloc-users mailing 
>> listhwloc-users@open-mpi.orghttp://www.open-mpi.org/mailman/listinfo.cgi/hwloc-users
>>
>>
>>
>> ___
>> hwloc-users mailing list
>> hwloc-us...@open-mpi.org
>> http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-users
>>
>
>

Re: [hwloc-users] misleading cache size on AMD Opteron 6348?

[Yury Vorobyov]

The BIOS has latest version. If I should check some BIOS information, I
have access to hardware. Tell me what variables from SMBIOS you want to see?


On Fri, Jan 31, 2014 at 1:07 PM, Brice Goglin  wrote:

>  Hello,
>
> Your BIOS reports invalid L3 cache information. On these processors, the
> L3 is shared by 6 cores, it covers 6 cores of an entire half-socket NUMA
> node. But the BIOS says that some L3 are shared between 4 cores, others by
> 6 cores. And worse it says that some L3 is shared by some cores from a NUMA
> node and others from another NUMA nodes, which causes the error message
> (and these L3 cannot be inserted in the topology).
>
> I see "AMD Eng Sample, ZS268145TCG54_32/26/20_2/16" in the processor type,
> so it might explain why your BIOS is somehow experimental. See if you can
> upgrade it.
>
> Also make sure your kernel isn't too old in case it misses L3 info for
> these processors. At least 3.3 should be OK iirc.
>
> NUMA node sharing info:
> $ cat sys/devices/system/node/node*/cpumap
> ,003f
> ,0fc0
> ,0003f000
> ,00fc
> $ cat sys/devices/system/cpu/cpu{?,??}/cache/index3/shared_cpu_map
> ,000f << wrong, should be 003f
> ,000f << wrong, should be 003f
> ,000f << wrong, should be 003f
> ,000f << wrong, should be 003f
> ,03f0 < ,03f0 < ,03f0 < ,03f0 < ,03f0 < ,03f0 < ,0c00 < ,0c00 < ,3000 < ,3000 < ,000fc000 < ,000fc000 < ,000fc000 < ,000fc000 < ,000fc000 < ,000fc000 < ,00f0 < ,00f0 < ,00f0 < ,00f0 <
> Brice
>
>
>
> Le 31/01/2014 03:46, Yury Vorobyov a écrit :
>
>  I have got error about "intersecting caches".
>
>  Info from hwloc in attachments.
>
>  I never got this before. I use "live" builds of OpenMPI directly from
> repo.
>
>
> ___
> hwloc-users mailing 
> listhwloc-users@open-mpi.orghttp://www.open-mpi.org/mailman/listinfo.cgi/hwloc-users
>
>
>
> ___
> hwloc-users mailing list
> hwloc-us...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-users
>

Re: [hwloc-users] [hwloc-announce] Hardware locality (hwloc) v1.9 released

[Brice Goglin]

That's exactely why we have plugin support. You can pass
--enable-plugins so that all plugin-able backends are built as separate
hwloc_foo.so files that are used only when available/loaded at runtime.
Then you can put them in different packages and hwloc will only load the
available ones.

For instance, if libxnvctrl is the only lib that you don't want libhwloc
to depends against, you put hwloc_gl.so in a separate package (you can
even tell hwloc to build only gl as a plugin with --enable-plugins=gl).

On Debian, the libhwloc package "recommends" libhwloc-plugins ("heavy"
external dependencies: libxml, pci and libxml) and "suggests"
libhwloc-contrib-plugins (non-free external dependencies: cuda, gl) and
people are free to install what they really want. If they don't install
any plugin package, they still get support for all operating systems,
the Linux-specific PCI backend, the x86-specific backend and the
"minimalistic" XML backend. Not too bad :)

Another solution could be to build and distribute all plugins in the
main hwloc package but don't have it depend on the plugin dependencies.
hwloc tries to load all plugins, but it fails when dependene libraries
are missing. So the CUDA plugin is only loaded if libcuda is installed.
Can be convenient, but some distros won't let you do that.

Beware that there's an ABI version number for plugins. It may change in
the future.

Brice






Le 01/04/2014 12:23, Jiri Hladky a écrit :
> Hi Brice,
>
> I'm sorry for the double report. Now when you wrote it I remember that
> I have reported it:-)
>
> Thanks for fixing the man page.
>
> I have one more question: RHEL has splitted hwloc into 2 subpackages
> * hwloc 
> * hwloc-gui (it contains merely lstopo)
>
> The former one does not need any X11 dependencies. 
>
> I have now tried to do the same for Fedora but it's not so easy. On
> Fedora I build the package with libXNVCtrl but
> libXNVCtrl needs libX11. So even CLI tools need libX11:
>
> ldd lstopo-no-graphics
> linux-vdso.so.1 =>  (0x7fffbf1cb000)
> libhwloc.so.5 => /dev/shm/usr/lib/libhwloc.so.5
> (0x7f7a5277c000)
> libnuma.so.1 => /lib64/libnuma.so.1 (0x003c06a0)
> libpciaccess.so.0 => /lib64/libpciaccess.so.0 (0x003c05e0)
> libXNVCtrl.so.0 => /lib64/libXNVCtrl.so.0 (0x7f7a52545000)
> libXext.so.6 => /lib64/libXext.so.6 (0x003c07a0)
> libX11.so.6 => /lib64/libX11.so.6 (0x003c0760)
>
> Is there any way around? (On RHEL it's easy. RHEL does not provide
> libXNVCtrl at all so the package is built without it.
> Then lstopo-no-graphics does not depend on libX11)
>
> I currently see two options:
> A) Accept the fact that lstopo-no-graphics depends on X11. The number
> of dependencies for lstopo (from hwloc-gui package) is still much
> lower compared to  lstopo-no-graphics
> B) Compile it without libXNVCtrl but it will reduce the functionality.
>
> Is there any 3rd option? I guess not. It seems like A) is the best
> choice for Fedora. 
>
> Any ideas on that?
>
> Thanks!
> Jirka
>
>
>
>
> On Tue, Apr 1, 2014 at 10:54 AM, Brice Goglin  > wrote:
>
> Le 01/04/2014 10:43, Jiri Hladky a écrit :
> > Hi Brice,
> >
> > I see some compiler warnings when building rpm package for Fedora:
> >
> > topology-windows.c: In function
> 'hwloc_win_get_VirtualAllocExNumaProc':
> > topology-windows.c:338:30: warning: assignment from incompatible
> > pointer type [enabled by default]
> > topology-windows.c:343:28: warning: assignment from incompatible
> > pointer type [enabled by default]
> > topology-windows.c: In function 'hwloc_look_windows':
> > topology-windows.c:500:36: warning: assignment from incompatible
> > pointer type [enabled by default]
> > topology-windows.c:501:38: warning: assignment from incompatible
> > pointer type [enabled by default]
> >
>
> You already reported those on February 13th and we replied that
> they are
> harmless :)
>
> Moreover, these warnings come from make check under tests/ports when
> verifying that the Windows backend builds fine using "emulated"
> Windows
> headers under Linux. Something that for sure cannot be perfect. If you
> have a way to ignore make check warnings, at least under tests/ports,
> that'd be good.
>
>
> > hwloc_backends.c: In function 'main':
> > hwloc_backends.c:42:10: warning: ignoring return value of 'mkstemp',
> > declared with attribute warn_unused_result [-Wunused-result]
>
> Another warning from make check. We mostly don't care, I'll see if
> I can
> fix it.
>
> I am fixing the manpage problem and backporting it.
>
> thanks!
> Brice
>
> ___
> hwloc-users mailing list
> hwloc-us...@open-mpi.org 
> 

Re: [hwloc-users] [hwloc-announce] Hardware locality (hwloc) v1.9 released

[Jiri Hladky]

Hi Brice,

I'm sorry for the double report. Now when you wrote it I remember that I
have reported it:-)

Thanks for fixing the man page.

I have one more question: RHEL has splitted hwloc into 2 subpackages
* hwloc
* hwloc-gui (it contains merely lstopo)

The former one does not need any X11 dependencies.

I have now tried to do the same for Fedora but it's not so easy. On Fedora
I build the package with libXNVCtrl but libXNVCtrl needs libX11. So even
CLI tools need libX11:

ldd lstopo-no-graphics
linux-vdso.so.1 =>  (0x7fffbf1cb000)
libhwloc.so.5 => /dev/shm/usr/lib/libhwloc.so.5 (0x7f7a5277c000)
libnuma.so.1 => /lib64/libnuma.so.1 (0x003c06a0)
libpciaccess.so.0 => /lib64/libpciaccess.so.0 (0x003c05e0)
libXNVCtrl.so.0 => /lib64/libXNVCtrl.so.0 (0x7f7a52545000)
libXext.so.6 => /lib64/libXext.so.6 (0x003c07a0)
libX11.so.6 => /lib64/libX11.so.6 (0x003c0760)

Is there any way around? (On RHEL it's easy. RHEL does not provide
libXNVCtrl at all so the package is built without it.
Then lstopo-no-graphics does not depend on libX11)

I currently see two options:
A) Accept the fact that lstopo-no-graphics depends on X11. The number of
dependencies for lstopo (from hwloc-gui package) is still much lower
compared to  lstopo-no-graphics
B) Compile it without libXNVCtrl but it will reduce the functionality.

Is there any 3rd option? I guess not. It seems like A) is the best choice
for Fedora.

Any ideas on that?

Thanks!
Jirka




On Tue, Apr 1, 2014 at 10:54 AM, Brice Goglin  wrote:

> Le 01/04/2014 10:43, Jiri Hladky a écrit :
> > Hi Brice,
> >
> > I see some compiler warnings when building rpm package for Fedora:
> >
> > topology-windows.c: In function 'hwloc_win_get_VirtualAllocExNumaProc':
> > topology-windows.c:338:30: warning: assignment from incompatible
> > pointer type [enabled by default]
> > topology-windows.c:343:28: warning: assignment from incompatible
> > pointer type [enabled by default]
> > topology-windows.c: In function 'hwloc_look_windows':
> > topology-windows.c:500:36: warning: assignment from incompatible
> > pointer type [enabled by default]
> > topology-windows.c:501:38: warning: assignment from incompatible
> > pointer type [enabled by default]
> >
>
> You already reported those on February 13th and we replied that they are
> harmless :)
>
> Moreover, these warnings come from make check under tests/ports when
> verifying that the Windows backend builds fine using "emulated" Windows
> headers under Linux. Something that for sure cannot be perfect. If you
> have a way to ignore make check warnings, at least under tests/ports,
> that'd be good.
>
>
> > hwloc_backends.c: In function 'main':
> > hwloc_backends.c:42:10: warning: ignoring return value of 'mkstemp',
> > declared with attribute warn_unused_result [-Wunused-result]
>
> Another warning from make check. We mostly don't care, I'll see if I can
> fix it.
>
> I am fixing the manpage problem and backporting it.
>
> thanks!
> Brice
>
> ___
> hwloc-users mailing list
> hwloc-us...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-users
>

Re: [hwloc-users] [hwloc-announce] Hardware locality (hwloc) v1.9 released

[Brice Goglin]

Le 01/04/2014 10:43, Jiri Hladky a écrit :
> Hi Brice,
>
> I see some compiler warnings when building rpm package for Fedora:
>
> topology-windows.c: In function 'hwloc_win_get_VirtualAllocExNumaProc':
> topology-windows.c:338:30: warning: assignment from incompatible
> pointer type [enabled by default]
> topology-windows.c:343:28: warning: assignment from incompatible
> pointer type [enabled by default]
> topology-windows.c: In function 'hwloc_look_windows':
> topology-windows.c:500:36: warning: assignment from incompatible
> pointer type [enabled by default]
> topology-windows.c:501:38: warning: assignment from incompatible
> pointer type [enabled by default]
>

You already reported those on February 13th and we replied that they are
harmless :)

Moreover, these warnings come from make check under tests/ports when
verifying that the Windows backend builds fine using "emulated" Windows
headers under Linux. Something that for sure cannot be perfect. If you
have a way to ignore make check warnings, at least under tests/ports,
that'd be good.


> hwloc_backends.c: In function 'main':
> hwloc_backends.c:42:10: warning: ignoring return value of 'mkstemp',
> declared with attribute warn_unused_result [-Wunused-result]

Another warning from make check. We mostly don't care, I'll see if I can
fix it.

I am fixing the manpage problem and backporting it.

thanks!
Brice

Re: [hwloc-users] [hwloc-announce] Hardware locality (hwloc) v1.9 released

[Jiri Hladky]

Hi Brice,

I see some compiler warnings when building rpm package for Fedora:

topology-windows.c: In function 'hwloc_win_get_VirtualAllocExNumaProc':
topology-windows.c:338:30: warning: assignment from incompatible pointer
type [enabled by default]
topology-windows.c:343:28: warning: assignment from incompatible pointer
type [enabled by default]
topology-windows.c: In function 'hwloc_look_windows':
topology-windows.c:500:36: warning: assignment from incompatible pointer
type [enabled by default]
topology-windows.c:501:38: warning: assignment from incompatible pointer
type [enabled by default]

hwloc_backends.c: In function 'main':
hwloc_backends.c:42:10: warning: ignoring return value of 'mkstemp',
declared with attribute warn_unused_result [-Wunused-result]

Could you please check it out?

Mercy!
Jirka


On Wed, Mar 26, 2014 at 12:48 PM, Brice Goglin wrote:

> The Hardware Locality (hwloc) team is pleased to announce the release
> of v1.9:
>
>http://www.open-mpi.org/projects/hwloc/
>
> v1.9 is a major new release series.
> It adds a couple enhanced API functions, many object attributes for
> better representing CPU and I/O device characteristics, and more.
>
> * API
>   + Add hwloc_obj_type_sscanf() to extend hwloc_obj_type_of_string() with
> type-specific attributes such as Cache/Group depth and Cache type.
> hwloc_obj_type_of_string() is moved to hwloc/deprecated.h.
>   + Add hwloc_linux_get_tid_last_cpu_location() for retrieving the
> last CPU where a Linux thread given by TID ran.
>   + Add hwloc_distrib() to extend the old hwloc_distribute[v]() functions.
> hwloc_distribute[v]() is moved to hwloc/deprecated.h.
>   + Don't mix total and local memory when displaying verbose object
> attributes
> with hwloc_obj_attr_snprintf() or in lstopo.
> * Backends
>   + Add CPUVendor, CPUModelNumber and CPUFamilyNumber info attributes for
> x86, ia64 and Xeon Phi sockets on Linux, to extend the x86-specific
> support added in v1.8.1. Requested by Ralph Castain.
>   + Add many CPU- and Platform-related info attributes on ARM and POWER
> platforms, in the Machine and Socket objects.
>   + Add CUDA info attributes describing the number of multiprocessors and
> cores and the size of the global, shared and L2 cache memories in CUDA
> OS devices.
>   + Add OpenCL info attributes describing the number of compute units and
> the global memory size in OpenCL OS devices.
>   + The synthetic backend now accepts extended types such as L2Cache, L1i
> or
> Group3. lstopo also exports synthetic strings using these extended
> types.
> * Tools
>   + lstopo
> - Do not overwrite output files by default anymore.
>   Pass -f or --force to enforce it.
> - Display OpenCL, CUDA and Xeon Phi numbers of cores and memory sizes
>   in the graphical output.
> - Fix export to stdout when specifying a Cairo-based output type
>   with --of.
>   + hwloc-ps
> - Add -e or --get-last-cpu-location to report where processes/threads
>   run instead of where they are bound.
> - Report locations as likely-more-useful objects such as Cores or
> Sockets
>   instead of Caches when possible.
>   + hwloc-bind
> - Fix failure on Windows when not using --pid.
> - Add -e as a synonym to --get-last-cpu-location.
>   + hwloc-distrib
> - Add --reverse to distribute using last objects first and singlify
>   into last bits first. Thanks to Jirka Hladky for the suggestion.
>   + hwloc-info
> - Report unified caches when looking for data or instruction cache
>   ancestor objects.
> * Misc
>   + Add experimental Visual Studio support under contrib/windows.
> Thanks to Eloi Gaudry for his help and for providing the first draft.
>   + Fix some overzealous assertions and warnings about the ordering of
> objects on a level with respect to cpusets. The ordering is only
> guaranteed for complete cpusets (based on the first bit in sets).
>   + Fix some memory leaks when importing xml diffs and when exporting a
> "too complex" entry.
>
> Changes since v1.9rc1 only consists in minor documentation updates.
>
> --
> Brice
>
> ___
> hwloc-announce mailing list
> hwloc-annou...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-announce
>