I've been playing with this some more and have it working, though I need Jeff to help resolve one lingering issue.
However, I ran across a couple of things that you folks are going to need to think about for Fedora: 1. the current libevent rpm doesn't include the header files, so users will need to install both libevent and libevent-headers. In addition, the current libevent rpm is built -without- thread support, which we require. Thus, it is missing the required libevent_pthreads library. We will detect the lack of this library and abort configure, so at least we won't build something that can't run. However, it does mean that your users won't be able to use the OMPI rpm unless you get some changes in the libevent rpm. 2. current libevent rpm version level for CentOS, at least, is very old - like version 1.4. We are currently using version 2.0.21, so you can see the gap. In fact, version 1.4 doesn't even contain some of the functions we require. I've added a test for this and will abort the configure in such cases. However, it again means your users may not be able to use the OMPI rpm - it'll just be a question of what libevent version is available on their platform. As we've been saying, we didn't just choose to include libevent without reason. It's a critical part of the OMPI system, and we have requirements both in terms of its revision level and how it is configured. I hope to have the external libevent support committed to the trunk, and then moved to the 1.7 branch in the upcoming weeks. It'll be up to you folks to figure out how you're going to make this all work :-/ Of course, users can always just build from source obtained from our web site... Ralph On May 2, 2013, at 5:52 AM, Jeff Squyres (jsquyres) <jsquy...@cisco.com> wrote: > 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/ > > > _______________________________________________ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel
