Hi Werner,

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.

Could you check if that makes dlltool superfluously for you? If so,
we can simplify the build script.

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

Reply via email to