Hi Arjen, > Well, I solved the problem: it turns out that Werner was on the right > track - I needed to expand the PATH environment variable, not with > the drivers subdirectory that contains the DLLs, but with the src > subdirectory, as apparently "test-drv-info" links to > "libplplot-9.6.1.dll"! > > I realised that something like this was going wrong by manually > running > it with various arguments and extra print-statements.
Interesting, I did the same, but there was nothing printed on the screen ever until I added all missing dlls to the PATH? > > (By the way: it is using libtool as supplied by Cygwin. Interestingly > when I forced it to use Werner's utilities, it did run! So, in that > case it does not seem to depend on libplplot-9.6.1.dll ...) The reason is, that I don't use PLplot function which provides the path to the driver directory. Cygwin runs on Windows after all and dlls must be in the same directory, in the PATH or in the system directories. So we have the choice now to use my implementation for libltdl or libtool, but then we must change the code for cygwin accordingly what I already did for my implementation. So it may be better to use my implementation after all. > >> I made some minor CMake changes to the way the code is built and >> run so >> probably the best bet is there is something wrong there for the >> Cygwin case >> (but not for the actual C-code itself). >> >>>> >>>> If our build system chooses libltdl, do you have the latest/ >>>> greatest >>>> version >>>> installed properly? >>>> >>> >>> Quite probably it is an old one, but as I said before: it has >>> worked in >>> a previous build. So my suspicion is that the relatively new >>> test-drv-info program does something different. I will try and find >>> out what that difference is. >> >> I have just double-checked by downloading get-drv-info.c (revision >> 9475) >> from our repository and it is identical to test-drv-info.c. So the >> issue is >> not due to a code change between get-drv-info.c and test-drv-info.c. >> > > No, it is indeed the PATH that requires attention. > > That brings me to the following question: is it possible to expand the > PATH variable automatically during the build process? I can of course > expand it before I start "make", but then we burden every user with > that. Putting that into the Makefiles seems much more elegant. Or at > the very least: that is what I think now. Yesterday, I had exactly the same idea as you. Just recently there was a discussion on the CMake mailing list about exactly this problem. I'll reread it and change the CBS accordingly. So that the dll directory is included to the path, so that test-drv-info is able to run without problems as well as the examples if you are using - DBUILD_TEST=ON. At least in the build tree anything works without any user interaction. But these changes to the PATH variable will not be permanently, so if you run the examples or test-drv-info by hand they won't work. Arjen, btw, in cygwin I have the same problem with the fortran 77 compiler (no import library created for libplplotf77d-9.1.1.dll) when I add -DBUILD_TEST=ON. Can you confirm that? Regards, Werner > > Regards, > > Arjen > > > Delft Hydraulics, GeoDelft, the Subsurface and Groundwater unit of > TNO and parts of Rijkswaterstaat have joined forces in a new > independent institute for delta technology, Deltares. Deltares > combines knowledge and experience in the field of water, soil and > the subsurface. We provide innovative solutions to make living in > deltas, coastal areas and river basins safe, clean and sustainable. > > > > DISCLAIMER: This message is intended exclusively for the > addressee(s) and may contain confidential and privileged > information. If you are not the intended recipient please notify the > sender immediately and destroy this message. Unauthorized use, > disclosure or copying of this message is strictly prohibited. > The foundation 'Stichting Deltares', which has its seat at Delft, > The Netherlands, Commercial Registration Number 41146461, is not > liable in any way whatsoever for consequences and/or damages > resulting from the improper, incomplete and untimely dispatch, > receipt and/or content of this e-mail. > > > > > > ------------------------------------------------------------------------------ > _______________________________________________ > Plplot-devel mailing list > Plplot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/plplot-devel -- Dr. Werner Smekal Institut fuer Allgemeine Physik Technische Universitaet Wien Wiedner Hauptstr 8-10 A-1040 Wien Austria email: sme...@iap.tuwien.ac.at web: http://www.iap.tuwien.ac.at/~smekal phone: +43-(0)1-58801-13463 (office), +43-(0)1-58801-13469 (laboratory) fax: +43-(0)1-58801-13499 ------------------------------------------------------------------------------ _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
