This web mail archive is frozen.
This page is part of a frozen web archive of this mailing list.
You can still navigate around this archive, but know that no new mails
have been added to it since July of 2016.
Click here to be taken to the new web archives of this list; it includes all the mails that are in this frozen archive plus all new mails that have been sent to the list since it was migrated to the new archives.
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...
On May 2, 2013, at 5:52 AM, Jeff Squyres (jsquyres) <jsquyres_at_[hidden]> wrote:
> On May 1, 2013, at 10:32 PM, Orion Poplawski <orion_at_[hidden]> 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
> For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
> devel mailing list