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.
Few months ago it was compiling nicely under Cygwin, Mingw and
Interix. They are definitively very Unix like environments so few
changes were required. All changes I made are now in the trunk, so I
expect a smooth compilation under all these environments. I used 2
compilers, the mingw gcc (supposed to generate Windows native
executables) as well as cl (the Microsoft compiler). I had to use the
latest beta of the libtool in order to get Windows support (more
precisely cl support).
The whole compilation took about 4 hours on my 2.5Ghz AMD processor.
Way to much to be usable for anything else than a proof of concept.
The main overhead come from the compilation environment, and all the
processes that get spawned. So, I decide to move toward a completely
Windows native version. I have 2 sets of solution and projects files
(for the free version of Visual Studio), one for building everything
as a static library and one for building everything as a shared
library. The compilation is taking now around 3 minutes on the same
Meanwhile, we added registry support, installation scripts, better
support for the atomic operations, better path management, threads,
critical sections and synchronization primitives, simple approach to
If anybody want to provide some help, I can distribute the project
On Mar 1, 2007, at 6:10 AM, Jeff Squyres wrote:
> George Bosilca at U. Tennessee is working on a native Windows port
> for Open MPI; I don't know if anyone has ever tried to compile or run
> it under cygwin.
> George -- can you comment?
> On Feb 27, 2007, at 10:00 PM, Ganapathi Kamath wrote:
>> Justing passing along some information about building on cygwin, if
>> else is trying.
>> Though I can't comment on whether the modifications are sound or
>> whether resulting build is workable, it just pushes through the
>> I made the following changes to revision 13777 off
>>> #include <sys/uio.h>
>>> #include <sys/uio.h>
>> < void opal_atomic_init(opal_atomic_lock_t* lock, int value);
>>> void opal_atomic_init(opal_atomic_lock_t* lock, int32_t value);
>>> #include <w32api/windows.h>
>> < #include "opal/mca/timer/windows/timer_windows_component.h"
>>> #include "opal/mca/timer/windows/timer_windows.h"
>> I am still trying to figure things out.
>> [SYRU212-168:02268] *** Process received signal ***
>> [SYRU212-168:02268] Signal: Segmentation fault (11)
>> [SYRU212-168:02268] Signal code: (23)
>> [SYRU212-168:02268] Failing at address: 0x610c5115
>> [SYRU212-168:02268] *** End of error message ***
>> 23 [main] ompi_info 2268 _cygtls::handle_exceptions: Exception:
>> 8485 [main] ompi_info 2268 open_stackdumpfile: Dumping stack
>> trace to
>> Program received signal SIGSEGV, Segmentation fault.
>> 0x61016525 in stack_info::walk () from /usr/bin/cygwin1.dll
>> (gdb) bt
>> #0 0x61016525 in stack_info::walk () from /usr/bin/cygwin1.dll
>> #1 0x7c859dcc in OutputDebugStringA ()
>> from /cygdrive/c/WINDOWS/system32/kernel32.dll
>> #2 0x40010006 in ?? ()
>> #3 0x00000000 in ?? ()
>> The build configuration options were
>> ./configure --prefix=/opt/openmpi/openmpi-1.2-svn/bin
>> users mailing list
> Jeff Squyres
> Server Virtualization Business Unit
> Cisco Systems
> users mailing list
"Half of what I say is meaningless; but I say it so that the other
half may reach you"