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 (r...@open-mpi.org) 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
> > us...@open-mpi.org
> > http://www.open-mpi.org/mailman/listinfo.cgi/users  
>  
> _______________________________________________
> users mailing list
> us...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/users
>  

-- 
Dominique

Reply via email to