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.
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):
Thanks for bringing the issue to our attention!
On Nov 3, 2013, at 7:23 AM, Ralph Castain <rhc_at_[hidden]> 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 <dominique.orban_at_[hidden]> 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 \
>> If requested, it will also add
>> 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
>>>> Dear list,
>>>> I'm a humble indirect user of Open-MPI. On OSX, my Open-MPI installation
>>> is supplied by the Homebrew package manager . Another package
>>> supplied by Homebrew is libevent.
>>>> I recently read on the dev list  a discussion about libevent
>>> having always been part of Open-MPI but being more apparent in
>>>> 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
>>>> 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) .
>>>> 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).
>>>>  http://brew.sh
>>>>  http://www.open-mpi.org/community/lists/devel/2013/04/12273.php
>>>>  https://github.com/mxcl/homebrew/issues/23642
>>>> users mailing list
>>> users mailing list
> users mailing list
For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/