> On 2014-10-15 10:28-0000 Arjen Markus wrote: > >> Hi everyone, >> >> I am trying to test the build under MinGW/MSYS, but I have run into a >> problem with the device drivers: >> The example programs can not find them, unless I set PLPLOT_DRV_DIR to the >> directory containing the .driver_info files. >> However, when I set that environment variable [to work around the >> issue above], the examples abort immediately, as they can not find the >> .pal or .fnt files. >> >> I thought it might have to do with the plInBuildTree() function: I >> run the programs from within the build tree, but MSYS uses the forward >> slash to indicate directory segments whereas Windows and the code for >> plInBuildTree() uses the backslash. >>
Hi Arjen (again): The result for the simple test of the MinGW-4.7.2/MSYS/Wine-1.6.1 platform was perfect for CMake-3.0.2. (Commit f61c742 gives the template setup file change necessary to update to that version for epa_build). Here is exactly what I did in case you are having trouble mimicking that good result. For convenience and reproducibility, I used epa_build to build and install all plplot-lite dependencies and plplot itself but with no epa_build run-time tests of those results. This was for our principal default build configuration (IMPORTANT, i.e., shared libraries and dynamic devices). No issues occurred for this simple epa_build without run-time tests (which I believe is your case as well with the build tests you do with your batch file approach). I then followed up with this simple run-time test: # Change directory from the top of the epa_build build tree # to the top of the "build_plplot_lite" build tree. bash.exe-3.1$ cd epa_build/Build/build_plplot_lite # Figure out what was in the dll subdirectory (note all the library # and device dll's are there): bash.exe-3.1$ ls dll _plplotc.pyd libplplot.dll libplplotf95.dll libplplottcltk_Main.dll mem.dll ps.dll libcsirocsa.dll libplplot.dll.a libplplotf95.dll.a libplplottcltk_Main.dll.a ntk.dll svg.dll libcsirocsa.dll.a libplplotada.dll libplplotf95c.dll libqsastime.dll null.dll wingcc.dll libcsironn.dll libplplotada.dll.a libplplotf95c.dll.a libqsastime.dll.a pdf.dll xfig.dll libcsironn.dll.a libplplotcxx.dll libplplottcltk.dll libtclmatrix.dll plplot_widgetmodule.dll libplf95demolib.a libplplotcxx.dll.a libplplottcltk.dll.a libtclmatrix.dll.a plplotluac.dll # Put the absolute form of that dll subdirectory at the top of the PATH # and run the test bash.exe-3.1$ PATH=$(pwd)/dll:$PATH bash.exe-3.1$ examples/c/x01c.exe -dev psc -o /z/tmp/test.psc There were no errors for this case, i.e., library and device driver dll's, *.fnt, and *.pal files were all found in the build tree. Furthermore, the /z/tmp/test.psc result was identical to the corresponding Linux result (except for the embedded date). In sum, there were perfect run-time results for this test so long as the PATH was set correctly. Since I also got perfect results in March for CMake-2.8.12.1 (downloaded from KitWare rather than built just like CMake-3.0.2 used for the present test) and for a much more comprehensive build and run time test that included everything above (and a whole lot more!), I conclude there cannot be a regression (at least for this simple test) between CMake-2.8.12.1 and CMake-3.0.2. or between the PLplot version in March and the PLplot version now. So that eliminates two possible reasons for this regression you have observed between your old successful MinGW/MSYS test results (or my present good test results) and your present bad test results. I have given enough detail above so you should be able to exactly replicate what I did using the batch file approach (which I believe you preferred to the epa_build approach in the past). So if you are positive you are mimicking my principal CMake configuration items (shared library build + dynamic devices) and the exact build and run-time test above, yet you still encounter an error in finding the dll's and the *.fnt and *.pal files, then I guess it is possible the source of the problem is some regression you have recently introduced into your batch files that setup the test (compared to what you did before when you got good run-time results). However I agree with a suggestion you made in your very latest post that there is a good possibility the regression in behaviour is between the MinGW-4.7.2 and old MSYS version consistent with that MinGW version that I am using for my tests and the more modern MinGW/MSYS you have currently installed. In other words, your MinGW/MSYS installation may be borked or just plain unstable (i.e., perhaps the modern version of MinGW you happen to be using is not as stable as MinGW-4.7.2 has proved to be for me). So I agree if it turns out you have no success mimicking the above simple run-time test for PLplot with your currently installed version of MinGW, you may want to experiment with different MinGW and MSYS versions to see if you can find a stable combination like I have done. Alternatively you may wish to try the independent project MinGW-w64/MSYS2 which apparently is considerably more bug-free than MinGW/MSYS and which also has a lot more features (more free software libraries available) according to a response to my questions about MSYS2 on _the mingw list_. I emphasize what list I asked the question on because normally that list is devoted to MinGW/MSYS so all this early-adopter enthusiasm for MinGW-w64/MSYS2 on that list surprised me. Therefore, I plan to try MinGW-w64/MSYS2 myself just as soon as the Wine gaps in Windows API that are required by the MinGW-w64/MSYS2 startup script are filled in, but it is taking quite a while for the Wine developers to even start to deal with those gaps so I doubt I will be able to try MinGW-w64/MSYS2 any time soon. In conclusion, my good run-time test result today for CMake-3.0.2 and my previous (March) good run time tests for CMake-2.8.12.1 shows the regression you have discovered cannot be in CMake or PLplot for at least the default build and simple run-time test described above. And if you are using the same batch script approach that you used before to set up the PLplot default build, the regression is unlikely to be caused by some problem within that batch file. So if you cannot replicate my good but simple test above for the default build, then I suggest you try installing some other version of MinGW, and if that does not work try installing MinGW-w64/MSYS2 using their completely different (from MinGW/MSYS) "Pacman" automatic installer described at <http://sourceforge.net/p/msys2/wiki/MSYS2%20installation/> and <https://wiki.archlinux.org/index.php/pacman> and which was apparently ported to Windows for MinGW-w64/MSYS2 from the ArchLinux distribution. Note, that MinGW/MSYS and MinGW-w64/MSYS2 are completely independent software packages (no common developers) which respectively are an ancient fork and a modern fork of Cygwin without all the Cygwin baggage, i.e, the executables built on either platform run without the large cygwin dll. So if you are already getting a good Cygwin run-time result for PLplot, then it is likely that MinGW-w64/MSYS2 will just work out of the box, with the same "lite" benefit as MinGW/MSYS, but with hundreds of FOSS libraries optionally available via the Pacman installer which is a Cygwin-like benefit without the cygwin dll penalty. So if a non-working run-time test provides the excuse (or maybe even without that excuse!) please take this opportunity to try MinGW-w64/MSYS2 to discover if that platform is going to work for PLplot (note, with Kitware binary version of CMake and not the Cygwin version). 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 __________________________ ------------------------------------------------------------------------------ Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://p.sf.net/sfu/Zoho _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
