Open MPI logo

Hardware Locality Users' Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Hardware Locality Users mailing list

Subject: Re: [hwloc-users] [hwloc-announce] Hardware locality (hwloc) v1.9 released
From: Jiri Hladky (hladky.jiri_at_[hidden])
Date: 2014-04-01 15:18:06


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 <Brice.Goglin_at_[hidden]> 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 => (0x00007fffbf1cb000)
> libhwloc.so.5 => /dev/shm/usr/lib/libhwloc.so.5
> (0x00007f7a5277c000)
> libnuma.so.1 => /lib64/libnuma.so.1 (0x0000003c06a00000)
> libpciaccess.so.0 => /lib64/libpciaccess.so.0 (0x0000003c05e00000)
> libXNVCtrl.so.0 => /lib64/libXNVCtrl.so.0 (0x00007f7a52545000)
> libXext.so.6 => /lib64/libXext.so.6 (0x0000003c07a00000)
> libX11.so.6 => /lib64/libX11.so.6 (0x0000003c07600000)
>
> 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 <Brice.Goglin_at_[hidden]>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-users_at_[hidden]
>> http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-users
>>
>
>
>
> _______________________________________________
> hwloc-users mailing listhwloc-users_at_[hidden]http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-users
>
>
>
> _______________________________________________
> hwloc-users mailing list
> hwloc-users_at_[hidden]
> http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-users
>