Gustavo,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 -- enable-mca-no-build=memory.
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.
george. 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 wheredlsym() 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 lookingin the wrong place, but apparently it is *not* part of the standard, at least as defined here: http://www.opengroup.org/onlinepubs/000095399/basedefs/dlfcn.h.htmlFair 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 isok, assuming you have a GNU version of dlfcn.h, but apparently this isnot 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 us...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/users
smime.p7s
Description: S/MIME cryptographic signature
