[OMPI users] OpenMPI v3.0 on Cygwin

[Llelan D.]

Can OpenMPI v3.0 be compiled for Cygwin64 on Windows 10?

Using:

./congifure --prefix=/usr/local
[blah, blah... Apparently successful (At least it doesn't say there's an error)]
make -j 12 all

I'm getting a slew of compiler errors about redefinitions between:

/usr/include/w32api/psdk_inc/_ip_types.h
or /usr/include/w32api/winsock2.h
and /usr/include/netdb.h
 or /usr/include/sys/socket.h

Are there magic variables, definitions, or switches for a Cygwin build
I'm missing?

[Marco Atzeri]

Post by Llelan D.
Can OpenMPI v3.0 be compiled for Cygwin64 on Windows 10?
./congifure --prefix=/usr/local
 [blah, blah... Apparently successful (At least it doesn't say there's
an error)]
make -j 12 all
       /usr/include/w32api/psdk_inc/_ip_types.h
    or /usr/include/w32api/winsock2.h
and    /usr/include/netdb.h
    or /usr/include/sys/socket.h
Are there magic variables, definitions, or switches for a Cygwin build
I'm missing?

Hi Llelan,
I assume no, and expect it needs some patches as I am slowing
doing for 2.1.2.
There are portion of the code that rise definitions that collides
with the Windows headers for not Cygwin programs.

After I finish on 2.1.2 I will look on 3.0.

Regards
Marco

[Llelan D.]

Post by Marco Atzeri
After I finish on 2.1.2 I will look on 3.0.

Thank you for your response. I am looking forward to a Cygwin release.
If you could send me some guidelines as to the preferred manner of doing
this as was done with previous versions, I could work on it myself. The
1.10 Cygport version compiles and packages just fine so I'll look at
what was done to that for now and try to translate it to v3.0.

@Jeffrey A Cummings: OpenMPI has abandoned *NATIVE* windows support
(*.lib for compilers like MSVC, etc.) and not Cygwin, though a v2.*
release has been slow. The msmpi package has never fully supported the
MPI specification (or even come close) and has been long (and silently)
abandoned by MS as people have preferred other fully compliant
implementations.

[Jeff Squyres (jsquyres)]

Post by Llelan D.

Post by Marco Atzeri
After I finish on 2.1.2 I will look on 3.0.

Thank you for your response. I am looking forward to a Cygwin release.
If you could send me some guidelines as to the preferred manner of doing this as was done with previous versions, I could work on it myself. The 1.10 Cygport version compiles and packages just fine so I'll look at what was done to that for now and try to translate it to v3.0.

Once you guys have some patches, let's have a look at them here upstream and see if we can slurp them in so that you don't have to carry them forward.

What would be *awesome* is if -- assuming we get those patches slurped in upstream -- someone could provide some testing resources:

1. For each Github pull request
2. Nightly MTT testing (doesn't have to be too extensive)

(I'm happy to explain the details of both of these if anyone has some resources to volunteer -- we should probably move over to the devel list, though)

Specifically: the biggest problem we have is that no one in the Open MPI developer community currently develops and test on Cygwin. Hence, if/when we break stuff, we don't know it until Marco has the cycles to test and then develop aftermarket patches. Meaning: if we get patches to make Open MPI compile/work on Cygwin, those will only last until we (accidentally) break it again. But if we have continual testing and integration on Cygwin (with all of our other CI infrastructure), that *significantly* decreases the probability of us breaking Cygwin again. Or, at least, if/when we break it, we'll *know* it, and therefore we can *fix* it.

Make sense?

[Jeffrey A Cummings]

The MS-MPI developers disagree with your statement below and claim to be actively working on MPI-3.0 compliance, with an expected new version release about every six month.

- Jeff

Jeffrey A. Cummings
Engineering Specialist
Performance Modeling and Analysis Department
Systems Analysis and Simulation Subdivision
Systems Engineering Division
Engineering and Technology Group
The Aerospace Corporation
571-304-7548
***@aero.org

-----Original Message-----
From: users [mailto:users-***@lists.open-mpi.org] On Behalf Of Llelan D.
Sent: Wednesday, September 27, 2017 3:22 PM
To: ***@lists.open-mpi.org
Subject: Re: [OMPI users] OpenMPI v3.0 on Cygwin

Post by Marco Atzeri
After I finish on 2.1.2 I will look on 3.0.

Thank you for your response. I am looking forward to a Cygwin release.
If you could send me some guidelines as to the preferred manner of doing this as was done with previous versions, I could work on it myself. The
1.10 Cygport version compiles and packages just fine so I'll look at what was done to that for now and try to translate it to v3.0.

@Jeffrey A Cummings: OpenMPI has abandoned *NATIVE* windows support (*.lib for compilers like MSVC, etc.) and not Cygwin, though a v2.* release has been slow. The msmpi package has never fully supported the MPI specification (or even come close) and has been long (and silently) abandoned by MS as people have preferred other fully compliant implementations.

[Llelan D.]

Post by Jeffrey A Cummings
The MS-MPI developers disagree with your statement below and claim to be actively working on MPI-3.0 compliance, with an expected new version release about every six month.

They can disagree as much as they want. I've spent over 30 years doing
contracts for and associated with MS and am very familiar with their
policy of what they claim vs. what they do. Check out:
  http://mpi-forum.org/slides/2014/11/mpi3-impl-status-Nov14.pdf
for where msmpi was in 2014 when they were claiming the same things. The
latest version of msmpi (v8.1.12438) still only provides minimal support
for MPI specification v2.0.

Understand, I'm no MS basher; Windows is still the most likely
development environment in the industry and must be respected. This is
why I always argue that it is a mistake not to distribute native MS
versions of packages no matter what level of popular support there is.
Allowing MS to restrict the level of support on the Windows platform to
only the avenues they wish developers to use is a huge restriction for
the evolution of a specification and a terrible problem for those of us
who must work cross-platform.

However, my original point was about the Cygwin version of openmpi and
not any native Windows version. Looking forward to that. :)

[Fab Tillier via users]

Hi Llelan,

Llelan D. wrote on Wed, 27 Sep 2017 at 19:06:23

Post by Llelan D.

Post by Jeffrey A Cummings
The MS-MPI developers disagree with your statement below and claim to
be actively working on MPI-3.0 compliance, with an expected new version
release about every six month.

They can disagree as much as they want. I've spent over 30 years doing
contracts for and associated with MS and am very familiar with their policy of
  http://mpi-forum.org/slides/2014/11/mpi3-impl-status-Nov14.pdf
for where msmpi was in 2014 when they were claiming
the same things. The latest version of msmpi (v8.1.12438) still only
provides minimal support for MPI specification v2.0.

Did you mean MPI 3.0 here? We've had comprehensive support for MPI 2.0 for quite some time, and as of version 8.1 believe we should be MPI 2.2 compliant as well as supporting a fair bit of MPI 3.0. We've been steadily adding MPI 3 support each release, and tend to prioritize development based on user feedback, so if there are APIs you need, please let us know - you can contact the MS-MPI team directly at mailto:***@microsoft.com.

You should be able to see the evolution through the MPICH BOF slides from past super computing conferences. The 2015 slides are here: https://www.mpich.org/files/2015/11/SC15-MPICH-BoF.pdf, but unfortunately the 2016 slides link is broken.

Post by Llelan D.
Understand, I'm no MS basher; Windows is still the most likely development
environment in the industry and must be respected. This is why I always
argue that it is a mistake not to distribute native MS versions of packages no
matter what level of popular support there is.
Allowing MS to restrict the level of support on the Windows platform to only
the avenues they wish developers to use is a huge restriction for the
evolution of a specification and a terrible problem for those of us who must
work cross-platform.

I think you misconstrue our objectives here. If there are APIs you would like us to support, let us know so that we can prioritize their implementation. We also don't prevent or discourage alternative implementations, and while we would be more than happy to see Windows native Open MPI releases, we understand and respect the Open MPI developers' decision to invest their time elsewhere.

Cheers,
-Fab

[George Bosilca]

On Thu, Sep 28, 2017 at 12:45 AM, Fab Tillier via users <

Post by Marco Atzeri
Hi Llelan,
Llelan D. wrote on Wed, 27 Sep 2017 at 19:06:23

Post by Llelan D.

Post by Jeffrey A Cummings
The MS-MPI developers disagree with your statement below and claim to
be actively working on MPI-3.0 compliance, with an expected new version
release about every six month.

They can disagree as much as they want. I've spent over 30 years doing
contracts for and associated with MS and am very familiar with their

policy of

Post by Llelan D.
http://mpi-forum.org/slides/2014/11/mpi3-impl-status-Nov14.pdf
for where msmpi was in 2014 when they were claiming
the same things. The latest version of msmpi (v8.1.12438) still only
provides minimal support for MPI specification v2.0.

Did you mean MPI 3.0 here? We've had comprehensive support for MPI 2.0
for quite some time, and as of version 8.1 believe we should be MPI 2.2
compliant as well as supporting a fair bit of MPI 3.0. We've been steadily
adding MPI 3 support each release, and tend to prioritize development based
on user feedback, so if there are APIs you need, please let us know - you
You should be able to see the evolution through the MPICH BOF slides from
https://www.mpich.org/files/2015/11/SC15-MPICH-BoF.pdf, but unfortunately
the 2016 slides link is broken.

The link to the slides presenting the level of support of the MPI
specification by different MPI implementations can be found on the main
page of the MPI Forum at http://mpi-forum.org/ (look for Implementation
Status).

George.

Post by Marco Atzeri

Post by Llelan D.
Understand, I'm no MS basher; Windows is still the most likely

development

Post by Llelan D.
environment in the industry and must be respected. This is why I always
argue that it is a mistake not to distribute native MS versions of

packages no

Post by Llelan D.
matter what level of popular support there is.
Allowing MS to restrict the level of support on the Windows platform to

only

Post by Llelan D.
the avenues they wish developers to use is a huge restriction for the
evolution of a specification and a terrible problem for those of us who

must

Post by Llelan D.
work cross-platform.

I think you misconstrue our objectives here. If there are APIs you would
like us to support, let us know so that we can prioritize their
implementation. We also don't prevent or discourage alternative
implementations, and while we would be more than happy to see Windows
native Open MPI releases, we understand and respect the Open MPI
developers' decision to invest their time elsewhere.
Cheers,
-Fab
_______________________________________________
users mailing list
https://lists.open-mpi.org/mailman/listinfo/users

[Jeffrey A Cummings]

The OpenMPI developers stopped supporting Windows a long time (several major versions) ago.

Microsoft has a free version of MPI for Windows available for download. There's no guarantee it will be free forever but it is free for now. I've been using it for about a year and it works for me. My usage of MPI is pretty vanilla so there may be features missing in Microsoft's implementation. It might be worth your while to at least look at it.

– Jeff

-----Original Message-----
From: users [mailto:users-***@lists.open-mpi.org] On Behalf Of Llelan D.
Sent: Wednesday, September 27, 2017 3:31 AM
To: ***@lists.open-mpi.org
Subject: [OMPI users] OpenMPI v3.0 on Cygwin

Can OpenMPI v3.0 be compiled for Cygwin64 on Windows 10?

Using:

./congifure --prefix=/usr/local
[blah, blah... Apparently successful (At least it doesn't say there's an error)] make -j 12 all

I'm getting a slew of compiler errors about redefinitions between:

/usr/include/w32api/psdk_inc/_ip_types.h
or /usr/include/w32api/winsock2.h
and /usr/include/netdb.h
 or /usr/include/sys/socket.h

Are there magic variables, definitions, or switches for a Cygwin build I'm missing?

_______________________________________________
users mailing list
***@lists.open-mpi.org
https://lists.open-mpi.org/mailman/listinfo/users