Hi Arjen, > > I think I found the cause: it was a bit hidden in directories I > normally > don't look at: I had a special CMake module for gfortran in > cmake/Modules/Platform. I never committed it, apparently, but now I > have.
That explains a lot ;) > > Could you check if that makes dlltool superfluously for you? If so, > we can simplify the build script. I didn't test it with MinGW 4/GFortran yet, but with Cygwin f77 and MinGW f77 - and both work now! So the files Cygwin-GNU-Fortran.cmake and Windows-GNU-Fortran.cmake also influence the f77 linker options. I tested only shared libraries so we still need to test for static, but that's great news. I'll revert my dlltool changes and commit them. Thanks, Werner > > I also checked if the compiler options I used for gfortran under MinGW > would do the job for Cygwin too and that is the case. So, my next move > will be to expand that module for gfortran under Cygwin as well. > (That would leave g95, I guess, as another popular compiler - should > be very much the same). > > Regards, > > Arjen > > On 2009-03-31 09:04, Werner Smekal wrote: >> 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 >> >> > > > 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 ------------------------------------------------------------------------------ This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
