George (or anyone else that can help),
I have been trying to build OpenMPI for windows (XP). But so far have
not been successful. I am trying to build version 1.3b2, because of
these emails, I have setup two virtual machine to do the windows builds,
one with cygwin installed and one with Microsoft Visual Studio 9.0
(express) installed.
Using slightly modified command that Gustavo used
./configure --prefix=/home/seabra/local/openmpi-1.3b1 \
--with-mpi-param_check=always --with-threads=posix \
--enable-mpi-threads --disable-io-romio \
--enable-mca-no-build=memory_mallopt,maffinity,paffinity \
--enable-contrib-no-build=vt \
CXX=g++
I was able to get configure to run, but the 'make all' failed. Before
trying to debug the Cygwin build (which is very slow), I want to try the
native windows build, but dont know how to proceed. Is there a MSVC
project file? Or should I use Cygwin to run configure, but use the
microsoft compiler and linker?
I have not yet looked into using SFU.
Thank you in advance
Nev
-----Original Message-----
From: George Bosilca <bosi...@eecs.utk.edu>
Reply-To: Open MPI Users <us...@open-mpi.org>
To: Open MPI Users <us...@open-mpi.org>
Subject: Re: [OMPI users] Fwd: Problems installing in Cygwin
List-Post: users@lists.open-mpi.org
Date: Thu, 30 Oct 2008 09:04:48 -0400
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
>>> 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:
>>
>> http://www.opengroup.org/onlinepubs/000095399/basedefs/dlfcn.h.html
>
> 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
> 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
