Re: [hwloc-devel] plugins inside plugin broken, as expected

[Jeff Squyres (jsquyres)]

On Jun 3, 2013, at 11:11 AM, Samuel Thibault  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
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

Re: [hwloc-devel] plugins inside plugin broken, as expected

[Samuel Thibault]

Brice Goglin, le Mon 03 Jun 2013 19:50:26 +0200, a écrit :
> Le 03/06/2013 10:52, Samuel Thibault a écrit :
> > Brice Goglin, le Mon 03 Jun 2013 10:46:49 +0200, a écrit :
> >> hwloc/bitmap.h is the biggest problem, plugins should be allowed to use
> >> all of them but there are many of them. Splitting hwloc-bitmap.so
> >> out of hwloc.so would be an easy way to solve this. The bitmap API is
> >> totally independent from the hwloc core anyway.
> > Having a libhwloc-plugin-helper.so for most functions is probably the
> > sanest way indeed.
> 
> If both plugins and the core libhwloc use these functions, is there a
> way to avoid having to pass both -lhwloc and -lhwloc-helper when linking
> normal hwloc applications?

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. We
can probably do that for the helpers we know for sure they have no
state, such as bitmap functions.

Samuel

Re: [hwloc-devel] plugins inside plugin broken, as expected

[Brice Goglin]

Le 03/06/2013 10:52, Samuel Thibault a écrit :
> Brice Goglin, le Mon 03 Jun 2013 10:46:49 +0200, a écrit :
>> hwloc/bitmap.h is the biggest problem, plugins should be allowed to use
>> all of them but there are many of them. Splitting hwloc-bitmap.so
>> out of hwloc.so would be an easy way to solve this. The bitmap API is
>> totally independent from the hwloc core anyway.
> Having a libhwloc-plugin-helper.so for most functions is probably the
> sanest way indeed.
>

If both plugins and the core libhwloc use these functions, is there a
way to avoid having to pass both -lhwloc and -lhwloc-helper when linking
normal hwloc applications? That doesn't matter for people using
pkg-config, but I guess some people hardwire -lhwloc on there link
command-line.

Brice

Re: [hwloc-devel] plugins inside plugin broken, as expected

[Samuel Thibault]

Brice Goglin, le Mon 03 Jun 2013 10:46:49 +0200, a écrit :
> hwloc/bitmap.h is the biggest problem, plugins should be allowed to use
> all of them but there are many of them. Splitting hwloc-bitmap.so
> out of hwloc.so would be an easy way to solve this. The bitmap API is
> totally independent from the hwloc core anyway.

Having a libhwloc-plugin-helper.so for most functions is probably the
sanest way indeed.

Samuel