2. My thoughts were preventing hwloc from going thru some of the pain that OMPI went thru w embedding. Libibverbs has the same problem. If you have middleware that uses plugins that, in turn, uses plugins, it's a bit complicated to support fully static builds properly (OMPI and hwloc do, but libibverbs doesn't easily, but still, it may require a rebuild of hwloc with enable-static). Also, the problem with opening DSOs in private namespaces still exists; there's no good solution for that (when both the middleware and hwloc use plugins).
>From hwlocs perspective, the middleware author can fix the static build option, but I figured: why even go here?
3. Open MPI also get flack for embedding lib ltdl and libevent. Although libltdl now has the built in options for using an external libltdl (which is what the distros use), why go down this road if we don't need to embed libltdl?
Sent from my phone. No type good.
On May 8, 2013, at 2:53 AM, "Brice Goglin" <Brice.Goglin_at_[hidden]> wrote:
> Actually, are we going too far here?
> 1) The original problem was that embedding couldn't build (it couldn't
> even autoreconf) because of the embedded ltdl. Not because of plugins
> being enabled. That's fixed with my patch and with yours.
> tests/embedded/ runs fine now.
> 2) Now, we're disallowing plugins entirely in the embedded case too.
> That's kind of orthogonal to (1). I don't think we currently have a
> single line of code to support this. If people want plugins and
> embedded, thay will need to setup ltdl in their own configure. I don't
> see any reason to prevent this. We may have users wanting this one day,
> so I think we should remove the current error message.
> 3) And we're disallowing included ltdl too. I am actually not against
> this one. We don't use advanced ltdl features, and I don't plan to
> change the plugin management code. So the installed ltdl should be fine.
> But now that (1) is fixed, there's no direct reason to do (3) immediately.
> hwloc-devel mailing list