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: Brice Goglin (Brice.Goglin_at_[hidden])
Date: 2014-04-01 06:58:04


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]
> <mailto: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] <mailto:hwloc-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