On May 1, 2013, at 10:32 PM, Orion Poplawski <or...@cora.nwra.com> wrote:
> Great! I'll try to take a look at next week. Hold off on this -- Ralph and I looked at this a bit closer, and the work is not quite complete yet (read: it doesn't work). > I noticed another message about using a threaded libevent after all on the > devel list. What is the status of that? Do we still need to produce a > non-threaded libevent in Fedora? Yes. We can look at porting this external libevent support to the v1.7 series (where we *don't* have threading enabled), but I honestly do not know how difficult that will be -- it's actually a fairly complex implementation on the trunk. As such, I can't promise that it will actually make it to the v1.7 series (it has already taken 10+ developer hours, with more to go -- and I don't know how much more on top of that will be required for a v1.7 port). That being said, I realize how allergic distros are to having duplicate libraries. But please very, very strongly consider that Open MPI has wholly embedded libevent FOR YEARS, and a) no one complained, b) no one cared, and c) no harm was done. The libevent copy is *wholly contained inside libopen-pal.so*, so it's not like anyone else can link against our libevent, anyway. In short: it's not externally visible. Yes, we made the fact that we are wholly embedding libevent more obvious in the v1.7 series, but it does not change history. Given that we definitely plan to make the external-libevent functionality available in the v1.9 series, it may be a LOT simpler to just allow Open MPI v1.7 to embed libevent. And then v1.9 will eventually fix the situation the way they want. -- Jeff Squyres jsquy...@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
