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...?
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 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. -- Gustavo Seabra Postdoctoral Associate Quantum Theory Project - University of Florida Gainesville - Florida - USA
