From: Alan W. I. <ir...@be...> - 2010-05-10 17:47:24
|
On 2010-05-10 09:14+0200 Werner Smekal wrote: >> [...]Therefore, I believe the only thing left to do (for those users >> who are building but not testing so they don't have their PATH set to dll) >> is to change the location of the test-drv-info executable to dll for the >> if(BUILD_SHARED_LIBS AND WIN32 AND NOT CYGWIN) case. If I can get that to >> work on Wine, I will commit the change (unless you beat me to it or unless >> you know of some reason why that wont work). > > I just commited the change. This works for me on MinGW. Hi Werner: Your commit was just what I had in mind. Thanks for dealing with this. I think life will be noticeably easier now for our Windows users who are just building and/or installing PLplot without testing it. BTW, I have just searched for /dll in the wiki and there are a large number of hits. From this result it appears to me the wiki needs some reorganization at this stage so that each Windows build section for a platform refers to the testing PLplot section without including any details of testing. That reorganization should get rid of many mentions of /dll since that subdirectory no longer needs to be on the PATH for a simple build/install without testing. I plan to make the proposed reorganizational changes for the MinGW build section and a new MinGW/MSYS build section once I have more experience with those two platforms under Wine, and I hope you do the same for the other Windows build sections as well. 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); PLplot scientific plotting software package (plplot.org); 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 __________________________ |
From: Arjen M. <arj...@de...> - 2010-05-06 14:27:32
|
Hi Alan, this is indeed very puzzling! I have never seen it before - and all the stuff I used I have used countless times before. I will try and reproduce it. As for the PostScript files: they look fine to me - there is nothing wrong with them. Also puzzling: why does a repeated invocation of test-drv-info via make examine different drivers? It must be recording some information. Regards, Arjen On 2010-05-06 16:22, Alan W. Irwin wrote: > > Hi Arjen: > > I presume you have done this exact test many times before on this platform. > So the question on my mind is what is different about this test compared to > your prior ones? For example, do you have the same issue for a PLplot > release that you know you have tested before on this platform? > > This test replication issue is a substantial part of the value of reporting > test results at > http://www.miscdebris.net/plplot_wiki/index.php?title=Testing_PLplot; once > you report a working test there then in future if there is some regression > you will have recorded in the table the exact revision number and the exact > platform that worked before for you. > > One other extremely puzzling thing about your report is that test-drv-info > just does a subset of what the PLplot library does with dynamic devices so > if it fails, the PLplot library should also fail to dynamically load the > device driver. So why is test-drv-info failing while the PLplot library is > (apparently) succeeding? Do the actual PLplot results you get from say the > psc device look fine in a PostScript viewer or are they blank or badly > rendered? > > 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); PLplot scientific plotting software > package (plplot.org); 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 > __________________________ > |
From: Arjen M. <arj...@de...> - 2010-05-06 14:37:24
|
Hi Alan, On 2010-05-06 16:27, Arjen Markus wrote: > Hi Alan, > > this is indeed very puzzling! I have never seen it before - and all > the stuff I used I have used countless times before. > > I will try and reproduce it. > It has disappeared! The only thing I can think of that is different is the path - previously I had a PATH variable that referred to another build directory (or more accurately: the DLL subdirectory there), so at some point I had to correct that. Now I corrected it immediately. Maybe that has caused the initial failure. > As for the PostScript files: they look fine to me - there is nothing > wrong with them. > > Also puzzling: why does a repeated invocation of test-drv-info via make > examine different drivers? It must be recording some information. > Of course, it is creating a copy of the rc-files - that is the information it is using. Consider this a strange but not important incident. (I will keep it in mind for future reference) Regards, Arjen |
From: David M. <da...@as...> - 2010-05-06 14:37:45
|
On May 6, 2010, at 7:27 , Arjen Markus wrote: > this is indeed very puzzling! I have never seen it before - and all > the stuff I used I have used countless times before. > > Also puzzling: why does a repeated invocation of test-drv-info via > make > examine different drivers? It must be recording some information. Have you tried from a clean build tree? Sometimes after making Makefile changes, old build products from previous builds can cause weird problems because make no longer considers them but the tools make invokes might consider/use them. Just an idea, Dave |
From: Arjen M. <arj...@de...> - 2010-05-06 14:40:38
|
On 2010-05-06 16:37, David MacMahon wrote: > > On May 6, 2010, at 7:27 , Arjen Markus wrote: > >> this is indeed very puzzling! I have never seen it before - and all >> the stuff I used I have used countless times before. >> >> Also puzzling: why does a repeated invocation of test-drv-info via make >> examine different drivers? It must be recording some information. > > Have you tried from a clean build tree? Sometimes after making Makefile > changes, old build products from previous builds can cause weird > problems because make no longer considers them but the tools make > invokes might consider/use them. > > Just an idea, > Dave > Hi Dave, thanks, but that was not the cause: I always rebuild from scratch. (Hm, but not just now ... I will have to re-examine this! And I need to keep track of seemingly unimportant glitches, like the one with the PATH I just mentioned) Regards, Arjen |
From: Alan W. I. <ir...@be...> - 2010-05-07 16:21:35
|
On 2010-05-07 08:54+0200 Arjen Markus wrote: > Hello all, > > I have done some tests wrt the strange error messages I got > from test-drv-info yesterday. It turns out that the program > is issuing an error code -1073741515 (completely nonsensical > of course) when it can not find the driver - the PATH environment > variable does not contain the directory containing the driver DLLs. It appears to me there is a good possibility you discovered a build-system issue here. If your PATH did not contain the directory where the driver DLL's are located, how come this was not an issue for running the examples in the build tree? In other words, is the build system doing the right thing with regard to the driver PATH for running build-tree examples for MinGW, but not for running test-drv-info? Even if there is a mundane explanation for your puzzling results (such as you had the wrong PATHs set for running test-drv-info, but you corrected that afterward for running the examples in the build tree), it appears to me we could make life substantially easier for those using the MinGW platform. Anyhow, there is a lot of power in CMake to make life easy for builders on all platforms. Let's use that power rather than demanding workarounds from our users such as adding extra paths when CMake might give us a better solution automatically. Assuming you do come up with a build-system fix to make life easier for our MinGW users, please think as generally as possible. For example, try to make the fix so that MinGW/MSYS, Cygwin, and bare Windows users benefit as well as MinGW users. 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); PLplot scientific plotting software package (plplot.org); 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 __________________________ |
From: Alan W. I. <ir...@be...> - 2010-05-09 15:13:48
|
On 2010-05-09 09:36+0200 Werner Smekal wrote: > The problem is, that in Windows dlls must either be in the same > directory as the executable (so test-drv-info must be in this directory > as well), or the PATH is set accordingly (this can't be set by cmake, > since the changes of cmake to the environment variables only last as > long cmake runs - so the changes are not anymore during compile time) or > if the dlls are in on of the system directories (no option). But test-drv-info is located in the same build-tree drivers subdirectory as the plug-in device drivers that it is testing. For example, here is the story on Linux for xwin: software@raven> ls /home/software/plplot_svn/HEAD/build_dir/drivers/xwin.so /home/software/plplot_svn/HEAD/build_dir/drivers/xwin.so* This is the relevant fragment of the the output from "make VERBOSE=1 test_dyndrivers" cd /home/software/plplot_svn/HEAD/build_dir/drivers && ./test-drv-info xwin > /home/software/plplot_svn/HEAD/build_dir/drivers/test_dyndrivers_dir/xwin.rc So according to your dll location criteria above, all should be well for finding the device-driver plug-ins. I guess there is a possibility that on the Windows side of things test-drv-info is not being executed in the build-tree drivers subdirectory or the dynamic device plug-ins are not located there. Could you please check that? I am now also wondering if there is some issue with ltdl_win32.c (the special code you wrote to dynamically load devices on Windows) such that it does not find the plug-in when it is in the same directory. Could you check that as well? I will also check both those issues for MinGW/MSYS on Wine, but that may be a special case so checking on a "real" windows platform would be a good idea as well. N.B. Remember that for such checking the test_dyndrivers target is only executed if you run it explicitly, or run the all or install targets. I plan to improve dependencies so that if you build a device it will get immediately checked by test-drv-info, but that hasn't happened yet. 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); PLplot scientific plotting software package (plplot.org); 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 __________________________ |
From: Arjen M. <arj...@de...> - 2010-05-10 07:18:45
|
Hi Alan, Werner, On 2010-05-09 17:13, Alan W. Irwin wrote: > > I am now also wondering if there is some issue with ltdl_win32.c (the > special code you wrote to dynamically load devices on Windows) such that it > does not find the plug-in when it is in the same directory. Could you > check that as well? > > I will also check both those issues for MinGW/MSYS on Wine, but that > may be a special case so checking on a "real" windows platform would be > a good idea as well. > > N.B. Remember that for such checking the test_dyndrivers target is only > executed if you run it explicitly, or run the all or install targets. I plan > to improve dependencies so that if you build a device it will get > immediately checked by test-drv-info, but that hasn't happened yet. > I will check further what is going wrong in the set-up (before Werner's latest change), as there must be some reason for the dynamic loading to fail in the case of test-drv-info and to succeed for the examples. As far as I can remember, I did not change the path between the invocation of make and the running of the examples (manually to just check the ones I changed). Hm, could it be the use of various environment variables and default paths in plGetDrvDir() and the like? Regards, Arjen |