Open MPI logo

Open MPI User's Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Open MPI User's mailing list

Subject: Re: [OMPI users] Conflict between OpenMPI 1.7.3 and libevent
From: Dominique Orban (dominique.orban_at_[hidden])
Date: 2013-11-05 10:44:24


Thanks for patch. Unless I'm completely confused, it is still not resolving the issue. I downloaded Open-MPI 1.7.3 and replaced the Makefile.am with the one obtained from a fresh svn checkout (I checked that your changes are in there).

But `make install` still leaves me with an `event2` subdirectory of `include`. I used the `--without-devel-headers` configure flag to be sure.

What am I doing wrong?

On 4 November, 2013 at 10:47:04 PM, Jeff Squyres (jsquyres) (jsquyres_at_[hidden]) wrote:
>
> Ralph raised this internally and we fixed it -- we had an error
> in a Makefile.am that was accidentally installing the libevent
> header files when we didn't mean them to be.
>
> If you can apply this patch to your Homebrew recipe, it should
> fix the issue (it'll be included in 1.7.4):
>
> https://svn.open-mpi.org/trac/ompi/changeset/29588
>
> Thanks for bringing the issue to our attention!
>
>
> On Nov 3, 2013, at 7:23 AM, Ralph Castain
> wrote:
>
> > I'll check into it - that shouldn't be happening and is probably
> an error in our configure logic somewhere.
> >
> > On Nov 3, 2013, at 7:15 AM, Dominique Orban
> wrote:
> >
> >> Thanks for the quick reply. That doesn't seem to be it though.
> Homebrew only uses the configure flags
> >>
> >> --prefix=... \
> >> --disable-dependency-tracking \
> >> --disable-silent-rules \
> >> --enable-ipv6
> >>
> >> If requested, it will also add
> >>
> >> --enable-mpi-thread-multiple
> >>
> >> I just tried compiling Open-MPI 1.7.3 by hand using
> >>
> >> ./configure --prefix=/tmp/ompi_install --disable-dependency-tracking
> --disable-silent-rules --enable-ipv6 --enable-mpi-thread-multiple
> --without-devel-headers
> >>
> >> and the 'event2' headers are still under /tmp/ompi_install/include.
> As far as I can tell, the conflict is still there.
> >>
> >>
> >> On 3 November, 2013 at 9:44:46 AM, Ralph Castain (rhc_at_[hidden])
> wrote:
> >>>
> >>> I'm unfamiliar with Homebrew, but it sounds like they created
> >>> the OMPI package --with-devel-headers for some reason.
> That
> >>> doesn't make a lot of sense for a distribution as it is only
> used
> >>> by OMPI developers who want access to OMPI internal functions
> >>> from inside a test suite.
> >>>
> >>> We unfortunately have no control over how 3rd party packagers
> >>> decide to build OMPI, which is why we generally advise building
> >>> it from source instead. In this case, nothing changed between
> >>> 1.6 and 1.7 - except that the packager decided to build it with
> >>> a different configure option.
> >>>
> >>> We include libevent in a completely "hidden" manner for one
> simple
> >>> reason - OMPI uses functions in libevent that are not present
> >>> in older versions of libevent that are typically the ones
> provided
> >>> by quite a few packagers (e.g., CentOS and Mac). Users of those
> >>> systems would find them unable to execute OMPI if we didn't,
> or
> >>> we'd have bizarre levels of code protection/branches throughout
> >>> OMPI to resolve all the use-cases for the wide range of libevent
> >>> versions out there.
> >>>
> >>> I'd suggest you "uninstall" the Homebrew package, and simply
> >>> download/build OMPI from the source code tarball. The problem
> >>> will then disappear.
> >>>
> >>>
> >>> On Nov 3, 2013, at 6:03 AM, Dominique Orban
> >>> wrote:
> >>>
> >>>> Dear list,
> >>>>
> >>>> I'm a humble indirect user of Open-MPI. On OSX, my Open-MPI
> installation
> >>> is supplied by the Homebrew package manager [1]. Another
> package
> >>> supplied by Homebrew is libevent.
> >>>>
> >>>> I recently read on the dev list [2] a discussion about libevent
> >>> having always been part of Open-MPI but being more apparent
> in
> >>> 1.7.3.
> >>>>
> >>>> At least on OSX, this causes unfortunate header file conflicts.
> >>> If a user were to install both libevent and Open-MPI by hand
> to
> >>> /usr/local (which is essentially what Homebrew does), one
> of
> >>> the two would obliterate the 'event2' header files of the
> other.
> >>> As far as I can tell, the 'event2' header files in Open-MPI
> differ
> >>> from those in libevent 2.0.21 (the version currently distributed
> >>> in Homebrew). This kind of conflict was absent from Open-MPI
> >>> 1.6.
> >>>>
> >>>> Homebrew supplies Open-MPI 1.7.3 by default because the
> compilers
> >>> shipped with the latest OSX development environment (Xcode
> >>> 5.0) fail to build Open-MPI 1.6.5 correctly (I do not use those
> >>> compilers myself, but I am told `make check` fails) [3].
> >>>>
> >>>> In view of the header file conflict, I'm wondering if there
> is
> >>> a strong argument for not keeping the libevent-related header
> >>> files of Open-MPI private. Stashing libevent-related stuff
> >>> to a private location could probably be done more easily than
> >>> adding logic to build Open-MPI against an external libevent.
> >>> It's unfortunate for Open-MPI to conflict in this way with
> seemingly
> >>> unrelated software packages that rely on libevent (e.g.,
> tmux).
> >>>>
> >>>> Thanks.
> >>>>
> >>>> --
> >>>> Dominique
> >>>>
> >>>> [1] http://brew.sh
> >>>> [2] http://www.open-mpi.org/community/lists/devel/2013/04/12273.php
> >>>> [3] https://github.com/mxcl/homebrew/issues/23642
> >>>> _______________________________________________
> >>>> users mailing list
> >>>> users_at_[hidden]
> >>>> http://www.open-mpi.org/mailman/listinfo.cgi/users
> >>>
> >>> _______________________________________________
> >>> users mailing list
> >>> users_at_[hidden]
> >>> http://www.open-mpi.org/mailman/listinfo.cgi/users
> >>>
> >>
> >> --
> >> Dominique
> >
> > _______________________________________________
> > users mailing list
> > users_at_[hidden]
> > http://www.open-mpi.org/mailman/listinfo.cgi/users
>
>
> --
> Jeff Squyres
> jsquyres_at_[hidden]
> For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
>
>

-- 
Dominique