On Thu, Oct 30, 2008 at 8:40 AM, Jeff Squyres wrote: > 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.
That should be good enough, at least for that part. Or testing first for the presence of OpenFabrics or Myricom? Maybe it could just test for the existence of GNU extensions? I don't know. I understand it must be really hard to keep track of what is standard and what is not these days. I'm just thankful that you guys are looking into it. Thanks! > 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? Well... I don't. It's just that, due to specifics of my work, I need to work on a Windows computer, but I also like to use many unix features / commands. So, I just use Cygwin out of convenience, which in a way gives me the best of both worlds without the need to dual boot. However, the other reason I use Cygwin is because I work in the development of a program and it is very convenient to do that in Cygwin, especially when I'm traveling and only have access to my laptop. Many users have this program running in Cygwin, so it's also good to have a place to test it. I don't really use Cygwin for the long "production" runs that would actually require a MPI, for that I have access to local clusters or Teragrid. My problem is testing the parallel version in Cygwin (or if any changes made break the parallel implementation) because I still did not manage to install a MPI in Cygwin. In fact, I have never tried a VM :-$ I guess I should give it a try sometime. Do you have any recommendations? My only requirements are that (i) it works, (ii) it's free. Thanks a lot!! -- Gustavo Seabra Postdoctoral Associate Quantum Theory Project - University of Florida Gainesville - Florida - USA
