Open MPI logo

Open MPI User's Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Open MPI User's mailing list

Subject: Re: [OMPI users] Fwd: Problems installing in Cygwin
From: Jeff Squyres (jsquyres_at_[hidden])
Date: 2008-10-30 08:40:55

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:

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