Open MPI logo

Hardware Locality Development Mailing List Archives

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

Subject: Re: [hwloc-devel] plugins inside plugin broken, as expected
From: Jeff Squyres (jsquyres) (jsquyres_at_[hidden])
Date: 2013-06-04 06:30:54

On Jun 3, 2013, at 11:11 AM, Samuel Thibault <samuel.thibault_at_[hidden]> wrote:

> If only plugins and the core use these functions, the application does
> not have to use -lhwloc-helper at all. If the application uses them
> (e.g. bitmap functions), then it would have to use -lhwloc-helper,
> but we can probably as well simply provide the symbols in both
> libhwloc-helper and libhwloc, so the application only needs -lhwloc.

I don't think you want to go that route -- you can end up with duplicate symbols, and there be dragons there.

> We
> can probably do that for the helpers we know for sure they have no
> state, such as bitmap functions.

I don't know if all these elaborate workarounds will be a Good Thing. You'll basically explore the dynamic linker space, in all of its glory/ugliness, and end up coming up with horrid, confusing workarounds.

The short version is: issues like this are the nature of DSOs.

Hwloc has a solution for this problem: build without DSO support, and all works fine. That should be the advertised solution, IMNSHO.

Until someone comes up with a more general, system-level solution to the problems of plugins loading plugins (e.g., some kind of flexible runtime linker namespace solution), individual user-level software packages cannot hope to sanely work around what is currently defined as the system model.

Jeff Squyres
For corporate legal information go to: