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
