(adding the list to CC)
Le 04/06/2013 13:35, Jeff Squyres (jsquyres) a écrit : > On Jun 4, 2013, at 4:10 AM, Brice Goglin <brice.gog...@inria.fr> wrote: > >>> I guess I'm asking - why can't that plugin link against an embedded >>> (non-DSO) hwloc? >> It can for sure. But if there's a hwloc package in your distrib (and >> this one usually has plugins enabled), people usually force you to use >> it instead of shipping another hwloc in your own package. > > Does hwloc support building its modules in libhwloc.la by default, but also > lt_dlopening any modules that it finds? > > If so, perhaps passing a flag to hwloc's init saying "don't open any plugins" > might be sufficient...? Once you pass --enable-plugins to get plugin loading support, you can still have both statically-built-in and plugin at the same time. The main point for making hwloc plugins was to avoid dependencies on crazy things like cuda/opencl/nvml/nvctrl/pci/libxml in the hwloc core. So only these components can be built as plugins, others are always static (Linux, x86, minimalistic xml without libxml). Adding topology flag to disable plugin may indeed be a nice workaround. As long as the hwloc user doesn't need what's in plugin, things will work fine. And I think things will work fine in the OpenCL case. Also, we have seen two behaviors: 1) OpenCL: the program aborts because the lazy symbol lookup fails, and we can't easily force BIND_NOW 2) custom test with ltdl: The program just silently fails to load hwloc symbols. Equivalent to passing the topology flag above. I hope we'll see (2) more often than (1) in the future. Brice
