On 2015-04-04 19:34-0000 Arjen Markus wrote: > Hi Alan, > > > >> -----Original Message----- >> From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca] >> Sent: Saturday, April 04, 2015 9:04 PM >> To: Arjen Markus >> Cc: Greg Jung; Phil Rosenberg; Jim Dishaw; PLplot development list >> Subject: RE: Release status: call for comprehensive testing: Cygwin >> >> Hi Arjen: >> >> It is very encouraging from my release manager perspective that all >> components of >> PLplot that you have enabled on Cygwin appear to be working for the shared >> case >> so long as you exclude the traditional build of the installed examples. >> >From the >> output that you attached it appears a number of different things went wrong >> with that >> traditional build and test of the installed examples. We can address those >> post- >> release. >> >> >> @Greg >> >> This (mostly) good result from Arjen on Cygwin obviously is sharply in >> contrast with >> your own results where not even ctest worked on that platform. Therefore, I >> suggest >> you get in touch with Arjen to figure out exactly what he did. Then >> following that >> procedure rigourously should give you similar good results, and probably >> even more >> importantly we should be able to document exactly what you did that should be >> avoided by others on Cygwin when they are running >> scripts/comprehensive_test.sh. >>
> Alan, are you sure it's Cygwin and not MSYS/MinGW where Greg's problems occur? On Cygwin even his initial make fails to build properly so clearly he is doing something on that platform that you are sucessfully avoiding. My very initial speculation there was he was not setting the environment variable correctly to tell CMake how to correctly interpret WIN32 and CYGWIN on his Cygwin platform, and that may still be the issue for him. To keep topics straight the rest of this (other than the last sentence) is about MSYS and MSYS2. On MSYS2 (I cannot recall whether Greg has tried MSYS) make works, but ctest completely fails at run-time. I have seen some strange effects myself for that platform [MinGW/MSYS], unfortunately. I have to set: > > set PLPLOT_DRV_DIR=.../drivers > > that is set that environment variable to the directory that holds the > *.drvinfo files, besides prepending the PATH variable with the directory > containing the DLLs, even though things are running in the build tree. I > think that is the same problem as Greg is experiencing with his MSYS/MinGW > set-up. The key code in question here is src/ltdl_win32.c where a call to LoadLibraryA dynamically loads the devices on Windows platforms. I have looked the documentation of that function at <https://msdn.microsoft.com/en-us/library/windows/desktop/ms684175(v=vs.85).aspx>. There is says for both LoadLibrary (what we used before) and LoadLibraryA that "... uses a standard search strategy to find the module; for more information, see the Remarks." Those remarks then refer to <https://msdn.microsoft.com/en-us/library/windows/desktop/ms682586(v=vs.85).aspx> where it says (item 6 in the order of what is searched for) that "The directories that are listed in the PATH environment variable." So from that you would conclude that if the devices are in the dll subdirectory, and that subdirectory is on your PATH, then the dll's corresponding to the device drivers should be found and ltdl_win32.c should just work. However, I must say that long Microsoft documentation trail has so many "ifs, and, and buts" that it leaves a lot of room for doubt that this whole process will work, and it is possible that the latest MSYS that you are using deliberately interferes with this process. So proceeding by experiment, the whole process has worked both for you and me historically when the call was to LoadLibrary, and I will soon be testing the current code where the call is to LoadLibraryA. But from that documentation trail, I don't think that distinction matters so I expect it will continue to work for me (since I continue to use exactly the same MSYS and Wine that worked for me before), and the issue may be in the more modern version of the classical MSYS that you are trying now. @Greg: For the MSYS2 case, you first might want to temporarily try changing the cmake logic in cmake/modules/drivers.cmake that currently reads if(ENABLE_DYNDRIVERS AND WIN32_OR_CYGWIN) if(NOT CYGWIN) set(LTDL_WIN32 ON) set(LTDL_INCLUDE_DIR ${CMAKE_SOURCE_DIR}/include) endif(NOT CYGWIN) endif(ENABLE_DYNDRIVERS AND WIN32_OR_CYGWIN) to set(LTDL_WIN32) i.e., to disable using the src/ltdl_win32.c code for the MSYS2 platform. The above full logic disables that approach just for the Cygwin case on Windows, and it is possible it should also be disabled for MSYS2. @Arjen: For my own MinGW/MSYS tests I am going to try both enabling and disabling the src/ltdl_win32.c approach to see whether both work for me. If so, I will permanently change to disabling src/ltdl_win32.c for the (classical) MSYS case since that approach might work for you as well. Anyhow, I will let you know how that goes, and I hope to hear back from you how your additional Cygwin testing has gone. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ ------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
