On Wed, Oct 29, 2008 at 1:49 PM, Jeff Squyres 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...?
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:
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...
So far, apparently, CYGWIN == POSIX (still), but CYGWIN != GNU.
Quantum Theory Project - University of Florida
Gainesville - Florida - USA