Open MPI logo

Open MPI User's Mailing List Archives

  |   Home   |   Support   |   FAQ   |  

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.

Subject: Re: [OMPI users] Fwd: Problems installing in Cygwin
From: George Bosilca (bosilca_at_[hidden])
Date: 2008-10-30 09:04:48


As Jeff mentioned this component is not required on Windows. You can
disable it completely in Open MPI and everything will continue to work
correctly. Please add --enable-mca-no-build=memory_mallopt o maybe the
more generic (as there is no need for any memory manager on Windows --

Just a word about performance. I think you already noticed how long
the configure step is, and believe it is fast compared with building
the whole Open MPI. However, once built, Open MPI (and most of Cygwin
applications) only see their performance slightly affected by the fact
they run on Cygwin. Even the network performances are correct.

It is possible to have a native version of Open MPI on Windows. There
are two ways to achieve this. First, install SFU, and compile there.
It worked last time I checked, but it's not the solution I prefer.
Second, you can install the express version of the Microsoft Visual
Studio (which is free), and set your PATH, LIB and INCLUDE correctly
to point to the installation, and then you can use the cl compiler to
build Open MPI even on Windows.


On Oct 30, 2008, at 8:40 AM, Jeff Squyres wrote:

> On Oct 29, 2008, at 4:31 PM, Gustavo Seabra wrote:
>>> Ugh. IMHO, Cygwin != POSIX.
>>> The problem is that we're making the assumption that if dlsym() is
>>> present,
>>> RTLD_NEXT is defined. I guess that's not true for cygwin (lame).
>>> I suppose
>>> that we could also check for RTLD_NEXT...? Is there any other OS
>>> where
>>> dlsym() is present by RTLD_NEXT is not?
>>> Would it be easier to run Linux in a virtual machine on your
>>> windows host?
>>> You'll probably get a lot better performance...?
>> Hi Jeff,
>> Are you sure RTLD_NEXT is part of the POSIX standard? I may be
>> looking
>> in the wrong place, but apparently it is *not* part of the standard,
>> at least as defined here:
> Fair enough -- my words were ambiguous, and probably overly broad.
> I was trying to convey that my prior experience with Cygwin has
> biased me to believe that Cygwin tends to be "different" than other
> POSIX-like OSs, such as Linux, Solaris, and OS X.
>> It would seem that this is a GNU extension, so it becomes available
>> when __USE_GNU is defined. Now, looking at the cygwin version of
>> dlfcn.h, I see that RTDL_NEXT is *not* defined, but RTDL_LAZY,
>> RTLD_NOW, RTLD_LOCAL and RTLD_GLOBAL, which makes it compliant with
>> POSIX, but not GNU.
>> The 'memory_mallopt_component.c' only checks if 'HAVE_DLSYM' is
>> defined. If so, it defines __USE_GNU then includes dlfcn.h. This is
>> ok, assuming you have a GNU version of dlfcn.h, but apparently this
>> is
>> not present in Cygwin...
> Understood; this was a more complete/precise meaning for my question
> "Is there any other OS where
> dlsym() is present by RTLD_NEXT is not?" I suppose we can extend
> the configure test to check for RTLD_NEXT as well. In this way,
> that component won't even decide to build itself. You won't need
> this component, because it's only really useful for the OpenFabrics
> and [ancient] Myricom GM drivers in Open MPI, neither of which are
> likely to be supported in Cygwin.
> Also FWIW, my understanding is that running another OS in a VM (such
> as Linux or your favorite BSD) will run *much* faster than Cygwin.
> I have dim recollections of LAM's and OMPI's "configure" script
> taking loooooong periods of time (I no longer have easy access to a
> Windows machine to do such testing). Those with more Windows
> experience than me attributed it to Windows' process model
> implementation, which is quite different than Linux/Solaris/OSX/
> etc. So I'm just curious: do you have a reason for preferring
> Cygwin instead of a VM?
> --
> Jeff Squyres
> Cisco Systems
> _______________________________________________
> users mailing list
> users_at_[hidden]

  • application/pkcs7-signature attachment: smime.p7s