On Nov 1, 2012, at 11:47 AM, marco atzeri <marco.atzeri_at_[hidden]> wrote:
> On 11/1/2012 5:08 PM, Ralph Castain wrote:
>> I think we'd be interested in looking at possibly adding this to the
>> code base. We still need to announce this (and will shortly), but our
>> Windows maintainer has moved on to other pastures. So support for native
>> Windows operations is ending with the 1.6 series, barring someone
>> stepping up to fill the void.
>> Having a cygwin alternative would let people at least continue to work
>> on the Windows platform, albeit in a different mode. Is this something
>> you are interested in pursuing?
> Hi Ralph,
> there is no special code on my packages, so deploying a cygwin package
> was already on my plan.
> It will be just an addition to the other packages for which I am already
> the cygwin package maintainer
> I want just to be sure that it works as expect before deploying it,
> and testing on a notebook is a bit limited.
> The only peculiarity I noticed is that the stripped binaries do
> not work, so the current package is based on unstripped installation.
> Other step is to look if other options can be enabled:
> LDFLAGS="-Wl,--export-all-symbols -no-undefined" \
> --disable-mca-dso \
> --without-udapl \
> --enable-cxx-exceptions \
> --with-threads=posix \
> --without-cs-fs \
> --enable-heterogeneous \
> --with-mpi-param_check=always \
> --enable-contrib-no-build=vt,libompitrace \
> at least "shmem-sysv" should be possible.
I see - that is even better than I had hoped! One question for you: does this only allow single-machine operations, or can people run across machines, assuming both are executing cygwin?
Guess I'm not sure how the latter would work, but my knowledge of cygwin is very old.
> users mailing list