From: Arjen M. <arj...@wl...> - 2008-10-02 20:04:16
|
Hello, I am picking up the issue of gfortran 4.3.2 under MinGW again. I have modified the source code (the import/export stuff) so that the libraries are created appropriately, but while building the examples, I run into the problem that the file "libplplotf77d.dll.a" is not found (there is a file "libplplotf77cd.dll.a" for the C-Fortran interfacing). I will check this problem, but may need some advice. Regards, Arjen |
From: Alan W. I. <ir...@be...> - 2008-10-02 23:26:37
|
On 2008-10-02 22:04+0200 Arjen Markus wrote: > Hello, > > I am picking up the issue of gfortran 4.3.2 under MinGW again. > I have modified the source code (the import/export stuff) so > that the libraries are created appropriately, but while > building the examples, I run into the problem that the file > "libplplotf77d.dll.a" is not found (there is a file "libplplotf77cd.dll.a" > for the C-Fortran interfacing). > > I will check this problem, but may need some advice. We need a lot more information before we can efficiently help you. To address that concern, here is what I would like you to do: To remove all extraneous issues and speed turnaround, please use CMake options to remove all bindings other than f77 and remove all devices other than ps. Then give us the exact cmake options you used, cmake.out, and make.out files (i.e., all results) from the cmake command and the "make VERBOSE=1" command. (That VERBOSE=1 option is important for obvious reasons.) In other words I would like the full information we normally request from ordinary PLplot users who report a problem. :-) If your current import/export changes should have no impact except for MinGW platforms, I suggest you go ahead a make a commit of your changes to trunk which Werner can then test. Otherwise, please go ahead and commit your changes to a branch that Werner can test without impacting the rest of us. 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...@wl...> - 2008-10-03 04:19:55
|
> On 2008-10-02 22:04+0200 Arjen Markus wrote: > >> Hello, >> >> I am picking up the issue of gfortran 4.3.2 under MinGW again. >> I have modified the source code (the import/export stuff) so >> that the libraries are created appropriately, but while >> building the examples, I run into the problem that the file >> "libplplotf77d.dll.a" is not found (there is a file >> "libplplotf77cd.dll.a" >> for the C-Fortran interfacing). >> >> I will check this problem, but may need some advice. > > We need a lot more information before we can efficiently help you. > > To address that concern, here is what I would like you to do: > ... > > In other words I would like the full information we normally request from > ordinary PLplot users who report a problem. :-) > Hi Alan, sure, this was mainly to let you know that I am picking it up again ;). I later realised that this is probably due to not exporting the routines in the Fortran bindings explicitly. So my plan is to experiment with this version of gfortran to see what happens when building small-size DLLs. I have digested enough material on the effects of dllimport and dllexport (and their GNU equivalents) to be sure I can solve the visibility problem. By stumbling on yesterday's problem, I have actually demonstrated solving one more step in the problem of finding the right combination of compiler/linker flags. I want to make sure that my changes do not affect the other platforms I have access to, before committing the stuff. The changes are fairly limited and they should be orthogonal (wonderful word :)) ... Regards, Arjen |
From: Arjen M. <arj...@wl...> - 2008-10-06 07:29:49
|
Alan W. Irwin wrote: >On 2008-10-02 22:04+0200 Arjen Markus wrote: > > > >>Hello, >> >>I am picking up the issue of gfortran 4.3.2 under MinGW again. >>I have modified the source code (the import/export stuff) so >>that the libraries are created appropriately, but while >>building the examples, I run into the problem that the file >>"libplplotf77d.dll.a" is not found (there is a file "libplplotf77cd.dll.a" >>for the C-Fortran interfacing). >> >>I will check this problem, but may need some advice. >> >> > >We need a lot more information before we can efficiently help you. > > Well, the cause of the problem is clear now: when linking the Fortran bindings into a DLL, gfortran would need the option -Wl,-out-implib,... (or something similar) to produce the missing library. This option _is_ present in the gcc part to create the DLL libplplotf77cd.dll. I checked to see if I could easily add it, but I have not found a specific CMake module for gfortran under Windows. So my question now is: Should I go ahead and add such module for this particular combination (as part of general modules) or add it to the CMakeLists.txt file as a special case. Or is there another way I should proceed? More details on the platform: - I am running CMake in an ordinary DOS-box under Windows XP. - I make sure that gcc and gfortran are in the path, so that CMake will pick up these compilers. - I use the "MinGW Makefiles" output option to generate the makefiles. (This differs from the situation where I run CMake via MSYS. MSYS and MinGW are explicitly distinguished in the CMake modules, but I am not sure how the above situation is characterised) Regards, Arjen |
From: Arjen M. <arj...@wl...> - 2008-10-06 08:34:42
|
Alan W. Irwin wrote: > On 2008-10-06 09:29+0200 Arjen Markus wrote: > >> Alan W. Irwin wrote: >> >>> On 2008-10-02 22:04+0200 Arjen Markus wrote: >>> >>> >>>> Hello, >>>> >>>> I am picking up the issue of gfortran 4.3.2 under MinGW again. >>>> I have modified the source code (the import/export stuff) so >>>> that the libraries are created appropriately, but while >>>> building the examples, I run into the problem that the file >>>> "libplplotf77d.dll.a" is not found (there is a file >>>> "libplplotf77cd.dll.a" >>>> for the C-Fortran interfacing). >>>> >>>> I will check this problem, but may need some advice. >>>> >>> >>> We need a lot more information before we can efficiently help you. >>> >> Well, the cause of the problem is clear now: when linking the Fortran >> bindings >> into a DLL, gfortran would need the option -Wl,-out-implib,... (or >> something >> similar) to produce the missing library. >> >> This option _is_ present in the gcc part to create the DLL >> libplplotf77cd.dll. >> >> I checked to see if I could easily add it, but I have not found a >> specific CMake >> module for gfortran under Windows. >> >> So my question now is: Should I go ahead and add such module for this >> particular >> combination (as part of general modules) or add it to the >> CMakeLists.txt file as >> a special case. Or is there another way I should proceed? > > > Hi Arjen: > > Assuming I understand the naming conventions properly, I think you > just need > another Platform file called Windows-GNU-Fortran.cmake with the > appropriate > gfortran flags corresponding to the equivalent C flags in > Windows-gcc.cmake. > The location for that file for some time to come should be > cmake/modules/Platform. Once you are happy with all the Fortran > compiler and > linking flags on MinGW, you will probably want to submit that file to the > CMake project to help others. Also in the distant future when our > minimum > CMake version corresponds to the version of CMake that includes that > Platform file, we can drop that file from PLplot. > > Here is how I came up with the above name. Currently on Linux the > gfortran > compiler and link flags are handled by Linux-GNU-Fortran.cmake. > Currently, > on Windows (MinGW) the gcc compiler and link flags are handled by > Windows-gcc.cmake. Combine the two and you get the name > Windows-GNU-Fortran.cmake. If that is right, you will see all the > flags set > there actually used for compilation and linking on MinGW with the > gfortran > compiler, but if that name is wrong the file will have no effect, and you > may have to experiment a little bit to get the correct name. > > Hope this advice helps to point you in the right direction. > Hi Alan, I think you are correct in that - I will try to solve the issue this way (better than messing up the logic in the Fortran bindings file) Regards, Arjen |
From: Arjen M. <arj...@wl...> - 2008-10-08 07:01:32
|
Alan W. Irwin wrote: > > Hi Arjen: > > Assuming I understand the naming conventions properly, I think you > just need > another Platform file called Windows-GNU-Fortran.cmake with the > appropriate > gfortran flags corresponding to the equivalent C flags in > Windows-gcc.cmake. > The location for that file for some time to come should be > cmake/modules/Platform. Once you are happy with all the Fortran > compiler and > linking flags on MinGW, you will probably want to submit that file to the > CMake project to help others. Also in the distant future when our > minimum > CMake version corresponds to the version of CMake that includes that > Platform file, we can drop that file from PLplot. > Hello Alan, you are quite right about the name of the module file for this OS/compiler combination: it is indeed Windows-GNU-Fortran.cmake. However, it has only effect if I put in the modules/platform directory of CMake itself. There is no effect whatsoever, if I put it under PLplot. Do you have any idea how I could enforce that? As long as that module is not in the official CMake distribution, it should be in PLplot, after all. Regards, Arjen |
From: Alan W. I. <ir...@be...> - 2008-10-08 09:09:41
|
On 2008-10-08 09:01+0200 Arjen Markus wrote: > Alan W. Irwin wrote: > >> >> Hi Arjen: >> >> Assuming I understand the naming conventions properly, I think you >> just need >> another Platform file called Windows-GNU-Fortran.cmake with the >> appropriate >> gfortran flags corresponding to the equivalent C flags in >> Windows-gcc.cmake. >> The location for that file for some time to come should be >> cmake/modules/Platform. Once you are happy with all the Fortran >> compiler and >> linking flags on MinGW, you will probably want to submit that file to the >> CMake project to help others. Also in the distant future when our >> minimum >> CMake version corresponds to the version of CMake that includes that >> Platform file, we can drop that file from PLplot. >> > Hello Alan, > > you are quite right about the name of the module file for this OS/compiler > combination: it is indeed Windows-GNU-Fortran.cmake. > > However, it has only effect if I put in the modules/platform directory of > CMake itself. There is no effect whatsoever, if I put it under PLplot. > > Do you have any idea how I could enforce that? As long as that module > is not in the official CMake distribution, it should be in PLplot, after > all. Try it now (after revision 8862). What I did was make a local copy of CMakeFortranInformation.cmake modified (I hope) to allow what you want (check for Fortran platform files in ${CMAKE_MODULE_PATH}/Platform). I have checked (with temporary message commands) that cmake/modules/CMakeFortranInformation.cmake is actually used by the CMake build system, and I have also checked that my modifications appear not to cause any issues for PLplot fortran on Linux. If this allows you to use ${CMAKE_MODULE_PATH}/Platform/Windows-GNU-Fortran.cmake (which for PLplot is cmake/modules/Platform/Windows-GNU-Fortran.cmake), I will be submitting the modified CMakeFortranInformation.cmake to the CMake project so we don't have to maintain it forever and also to help other people with the same issue. After all, the other languages allow use of platform files in ${CMAKE_MODULE_PATH}/Platform automatically because they use INCLUDE, and the changes I put in implement this same policy for Fortran. 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...@wl...> - 2008-10-08 09:14:37
|
Alan W. Irwin wrote: >Try it now (after revision 8862). What I did was make a local copy of >CMakeFortranInformation.cmake modified (I hope) to allow what you want >(check for Fortran platform files in ${CMAKE_MODULE_PATH}/Platform). I >have checked (with temporary message commands) that >cmake/modules/CMakeFortranInformation.cmake is actually used by the CMake >build system, and I have also checked that my modifications appear not to >cause any issues for PLplot fortran on Linux. > >If this allows you to use >${CMAKE_MODULE_PATH}/Platform/Windows-GNU-Fortran.cmake (which for PLplot is >cmake/modules/Platform/Windows-GNU-Fortran.cmake), I will be submitting the >modified CMakeFortranInformation.cmake to the CMake project so we don't have >to maintain it forever and also to help other people with the same issue. >After all, the other languages allow use of platform files in >${CMAKE_MODULE_PATH}/Platform automatically because they use INCLUDE, and >the changes I put in implement this same policy for Fortran. > > > Hi Alan, great! I will try this asap. Regards, Arjen |
From: Arjen M. <arj...@de...> - 2009-03-24 08:58:31
|
Hi Werner, very odd! I will delve into this myself :( Regards, Arjen On 2009-03-24 09:51, Werner Smekal wrote: > Hi Arjen, >> >> On 2009-03-24 09:38, Werner Smekal wrote: >>> Hi, >>> >>> I'm using the dynamic drivers and it exits with a message like >>> (translated from German): >>> >>> "The application could not be started, since (null).dll wasn't found. A >>> new installation of the application might solve the problem." >>> >>> Some problem converting C to Fortran strings? >>> >> >> Hi Werner, >> >> I can not imagine that that is the case! Such messages are typically >> produced by the run-time and system libraries. The (null) is very >> suspcious though - I have never seen it before. >> >> Could it be the compilers in your MinGW environment? > > The MinGW 3.4.5 toolset is the official one from mingw.org. The 4.3.3 > MinGW toolset is taken from http://www.tdragon.net/recentgcc/ which is > unofficial bot know to work. Since both compilers have the exactly same > problem I don't assume that the compiler toolset are the problem. I'm > using the Windows CLI though and not MSYS. > > 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. >> >> >> >> >> >> ------------------------------------------------------------------------------ >> >> Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are >> powering Web 2.0 with engaging, cross-platform capabilities. Quickly and >> easily build your RIAs with Flex Builder, the Eclipse(TM)based >> development >> software that enables intelligent coding and step-through debugging. >> Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com >> _______________________________________________ >> Plplot-devel mailing list >> Plp...@li... >> 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: sm...@ia... > 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. |
From: Werner S. <sm...@ia...> - 2009-03-25 20:47:01
|
[Repost due to mail configuration problem] Hi Arjen, > very odd! I will delve into this myself :( > I've already found the problem. The .def file needs something like LIBRARY libplplotf77d.dll at the top of the file at least for MinGW. Fortran 77 and 95 examples compile and work now. I'm sorry for the noise. Thanks, Werner > Regards, > > Arjen > > On 2009-03-24 09:51, Werner Smekal wrote: > >> Hi Arjen, >> >>> On 2009-03-24 09:38, Werner Smekal wrote: >>> >>>> Hi, >>>> >>>> I'm using the dynamic drivers and it exits with a message like >>>> (translated from German): >>>> >>>> "The application could not be started, since (null).dll wasn't found. A >>>> new installation of the application might solve the problem." >>>> >>>> Some problem converting C to Fortran strings? >>>> >>>> >>> Hi Werner, >>> >>> I can not imagine that that is the case! Such messages are typically >>> produced by the run-time and system libraries. The (null) is very >>> suspcious though - I have never seen it before. >>> >>> Could it be the compilers in your MinGW environment? >>> >> The MinGW 3.4.5 toolset is the official one from mingw.org. The 4.3.3 >> MinGW toolset is taken from http://www.tdragon.net/recentgcc/ which is >> unofficial bot know to work. Since both compilers have the exactly same >> problem I don't assume that the compiler toolset are the problem. I'm >> using the Windows CLI though and not MSYS. >> >> 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. >>> >>> >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> >>> Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are >>> powering Web 2.0 with engaging, cross-platform capabilities. Quickly and >>> easily build your RIAs with Flex Builder, the Eclipse(TM)based >>> development >>> software that enables intelligent coding and step-through debugging. >>> Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com >>> _______________________________________________ >>> Plplot-devel mailing list >>> Plp...@li... >>> 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: sm...@ia... >> 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. > > > > > > ------------------------------------------------------------------------------ > Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are > powering Web 2.0 with engaging, cross-platform capabilities. Quickly and > easily build your RIAs with Flex Builder, the Eclipse(TM)based development > software that enables intelligent coding and step-through debugging. > Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > 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 DVR-Nr: 0005886 email: sm...@ia... 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 |
From: Arjen M. <arj...@de...> - 2009-03-25 07:39:07
|
Hi Werner, glad you found that out, but I am slightly puzzled: - I do not recall ever needing that line - the actual line will depend on the option to use double-precision or not, so that complicates matters Furthermore, while trying to reproduce your problem I ran into one or two disturbing issues - an unexpected end-of-file in example x20f (with gfortran, f95 version), but on a temporary file. I need to sort that out. (As I had no connection to the Internet, yesterday, I could not update my working copy. I need to fix that first and then try again ...) Regards, Arjen On 2009-03-24 23:11, Werner Smekal wrote: > Hi Arjen, >> very odd! I will delve into this myself :( >> > I've already found the problem. The .def file needs something like > > LIBRARY libplplotf77d.dll > > at the top of the file at least for MinGW. Fortran 77 and 95 examples > compile and work now. I'm sorry for the noise. > > Thanks, > Werner >> Regards, >> >> Arjen >> >> On 2009-03-24 09:51, Werner Smekal wrote: >> >>> Hi Arjen, >>> >>>> On 2009-03-24 09:38, Werner Smekal wrote: >>>> >>>>> Hi, >>>>> >>>>> I'm using the dynamic drivers and it exits with a message like >>>>> (translated from German): >>>>> >>>>> "The application could not be started, since (null).dll wasn't >>>>> found. A >>>>> new installation of the application might solve the problem." >>>>> >>>>> Some problem converting C to Fortran strings? >>>>> >>>>> >>>> Hi Werner, >>>> >>>> I can not imagine that that is the case! Such messages are typically >>>> produced by the run-time and system libraries. The (null) is very >>>> suspcious though - I have never seen it before. >>>> >>>> Could it be the compilers in your MinGW environment? >>>> >>> The MinGW 3.4.5 toolset is the official one from mingw.org. The 4.3.3 >>> MinGW toolset is taken from http://www.tdragon.net/recentgcc/ which >>> is unofficial bot know to work. Since both compilers have the exactly >>> same problem I don't assume that the compiler toolset are the >>> problem. I'm using the Windows CLI though and not MSYS. >>> >>> 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. > >>>> >>>> >>>> >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> >>>> Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are >>>> powering Web 2.0 with engaging, cross-platform capabilities. Quickly >>>> and >>>> easily build your RIAs with Flex Builder, the Eclipse(TM)based >>>> development >>>> software that enables intelligent coding and step-through debugging. >>>> Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com >>>> _______________________________________________ >>>> Plplot-devel mailing list >>>> Plp...@li... >>>> 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: sm...@ia... >>> 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. >> >> >> >> >> >> ------------------------------------------------------------------------------ >> >> Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are >> powering Web 2.0 with engaging, cross-platform capabilities. Quickly and >> easily build your RIAs with Flex Builder, the Eclipse(TM)based >> development >> software that enables intelligent coding and step-through debugging. >> Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com >> _______________________________________________ >> Plplot-devel mailing list >> Plp...@li... >> https://lists.sourceforge.net/lists/listinfo/plplot-devel >> > > 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. |
From: Werner S. <sm...@ia...> - 2009-03-19 21:08:35
|
Hi Arjen, >> > Well, the cause of the problem is clear now: when linking the Fortran > bindings > into a DLL, gfortran would need the option -Wl,-out-implib,... (or > something > similar) to produce the missing library. > > This option _is_ present in the gcc part to create the DLL > libplplotf77cd.dll. I revisited this problem, since it still exists and wanted at least to make it work. > > I checked to see if I could easily add it, but I have not found a > specific CMake > module for gfortran under Windows. I tried to change the Windows-g77.cmake module but was not successful in adding this -Wl,-out-implib - I think this is maybe not possible, since there is no Fortran statement to export a symbol. I tried to add a .def file, but also no success. > > So my question now is: Should I go ahead and add such module for this > particular > combination (as part of general modules) or add it to the > CMakeLists.txt file as > a special case. Or is there another way I should proceed? > > More details on the platform: > - I am running CMake in an ordinary DOS-box under Windows XP. > - I make sure that gcc and gfortran are in the path, so that CMake > will pick up > these compilers. > - I use the "MinGW Makefiles" output option to generate the makefiles. > > (This differs from the situation where I run CMake via MSYS. MSYS and > MinGW are explicitly distinguished in the CMake modules, but I am not > sure how the above situation is characterised) I added now a custom post-build target, which runs dlltool to create the import library. Works great so far. Arjen, could you test that. Only implemented for f77 so far, f95 would be straight forward. If we manage to improve the cmake files we can remove it again. Example 23 doesn't compile now. I get the following message: [ 77%] Building Fortran object examples/f77/CMakeFiles/x23f.dir/x23f.f.obj Z:\DevZone\PLdev\build\gcc\debug\examples\f77\x23f.f: In program `x23f': Z:\DevZone\PLdev\build\gcc\debug\examples\f77\x23f.f:320: warning: & trim(family(ifamily+1))//' '//trim(style(istyle+1))//' '// ^ Reference to unimplemented intrinsic `TRIM' at (^) (assumed EXTERNAL) Z:\DevZone\PLdev\build\gcc\debug\examples\f77\x23f.f:320: & trim(family(ifamily+1))//' '//trim(style(istyle+1))//' '// ^ Invalid declaration of or reference to symbol `trim' at (^) [initially seen at (^)] mingw32-make[2]: *** [examples/f77/CMakeFiles/x23f.dir/x23f.f.obj] Error 1 mingw32-make[1]: *** [examples/f77/CMakeFiles/x23f.dir/all] Error 2 mingw32-make: *** [all] Error 2 My Fortran knowledge is not very exhaustive. Any ideas? Best Regards, Werner > > Regards, > > Arjen > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > ------------------------------------------------------------------------ > > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > 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 DVR-Nr: 0005886 email: sm...@ia... 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 |
From: Arjen M. <arj...@de...> - 2009-03-20 07:41:52
|
Hi Werner, right, my Fortran compiler is usually gfortran or g95 - g77 is a very old compiler that is no longer actively maintained. I can imagine that the compiler does not produce import libraries - shared libraries under Windows simply have too many pecularities, so they are probably beyond g77's capabilities. dlltool is the way forward here. As to x23f: the trim() function is not a FORTRAN 77 function. It was introduced in Fortran 90. (This does not show up when you use an F90 compiler - sigh) I will look into this one. Regards, Arjen On 2009-03-19 22:08, Werner Smekal wrote: > Hi Arjen, >>> >> Well, the cause of the problem is clear now: when linking the Fortran >> bindings >> into a DLL, gfortran would need the option -Wl,-out-implib,... (or >> something >> similar) to produce the missing library. >> >> This option _is_ present in the gcc part to create the DLL >> libplplotf77cd.dll. > I revisited this problem, since it still exists and wanted at least to > make it work. >> >> I checked to see if I could easily add it, but I have not found a >> specific CMake >> module for gfortran under Windows. > I tried to change the Windows-g77.cmake module but was not successful in > adding this -Wl,-out-implib - I think this is maybe not possible, since > there is no Fortran statement to export a symbol. I tried to add a .def > file, but also no success. >> >> So my question now is: Should I go ahead and add such module for this >> particular >> combination (as part of general modules) or add it to the >> CMakeLists.txt file as >> a special case. Or is there another way I should proceed? >> >> More details on the platform: >> - I am running CMake in an ordinary DOS-box under Windows XP. >> - I make sure that gcc and gfortran are in the path, so that CMake >> will pick up >> these compilers. >> - I use the "MinGW Makefiles" output option to generate the makefiles. >> >> (This differs from the situation where I run CMake via MSYS. MSYS and >> MinGW are explicitly distinguished in the CMake modules, but I am not >> sure how the above situation is characterised) > I added now a custom post-build target, which runs dlltool to create the > import library. Works great so far. Arjen, could you test that. Only > implemented for f77 so far, f95 would be straight forward. If we manage > to improve the cmake files we can remove it again. > > Example 23 doesn't compile now. I get the following message: > > [ 77%] Building Fortran object examples/f77/CMakeFiles/x23f.dir/x23f.f.obj > Z:\DevZone\PLdev\build\gcc\debug\examples\f77\x23f.f: In program `x23f': > Z:\DevZone\PLdev\build\gcc\debug\examples\f77\x23f.f:320: warning: > & trim(family(ifamily+1))//' '//trim(style(istyle+1))//' '// > ^ > Reference to unimplemented intrinsic `TRIM' at (^) (assumed EXTERNAL) > Z:\DevZone\PLdev\build\gcc\debug\examples\f77\x23f.f:320: > & trim(family(ifamily+1))//' '//trim(style(istyle+1))//' '// > ^ > Invalid declaration of or reference to symbol `trim' at (^) [initially > seen at (^)] > mingw32-make[2]: *** [examples/f77/CMakeFiles/x23f.dir/x23f.f.obj] Error 1 > mingw32-make[1]: *** [examples/f77/CMakeFiles/x23f.dir/all] Error 2 > mingw32-make: *** [all] Error 2 > > My Fortran knowledge is not very exhaustive. Any ideas? > > Best Regards, > Werner >> >> Regards, >> >> Arjen >> >> ------------------------------------------------------------------------ >> >> ------------------------------------------------------------------------- >> This SF.Net email is sponsored by the Moblin Your Move Developer's >> challenge >> Build the coolest Linux based applications with Moblin SDK & win great >> prizes >> Grand prize is a trip for two to an Open Source event anywhere in the >> world >> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Plplot-devel mailing list >> Plp...@li... >> https://lists.sourceforge.net/lists/listinfo/plplot-devel >> > > 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. |
From: Werner S. <sm...@ia...> - 2009-03-24 08:34:20
|
Hi Arjen, > > right, my Fortran compiler is usually gfortran or g95 - g77 is a very > old compiler that is no longer actively maintained. I can imagine > that the compiler does not produce import libraries - shared libraries > under Windows simply have too many pecularities, so they are probably > beyond g77's capabilities. dlltool is the way forward here. What I don't understand is, why it works for you (gfortran), since with MinGW 4.3.2 and gfortran 4.3.2 I have the same problems (no import library). In the CMakeLists.txt (for both f77 and f95) we add a .def file if(WIN32 AND BUILD_SHARED_LIBS AND NOT MINGW) SET(plplotf95${LIB_TAG}_LIB_SRCS ${plplotf95${LIB_TAG}_LIB_SRCS} plplotf95.def) endif(WIN32 AND BUILD_SHARED_LIBS AND NOT MINGW) What is cmake supposed to do with this file? If you add the .def file, does CMake automatically create a import library? For which compiler? If I do this for the MinGW compiler no import library is created. I understand that Fortran doesn't provide this dllimport/dllexport keywords and you need to create the import library later. But does that work for other compilers? And why does it work for you? If there is a case where it works for gfortran we need to alter the cmake files. In the moment it works for my compiler toolset (MinGW/g77 and MinGW/ gfortran), but we should test that for other combinations as well. Thanks, Werner > > As to x23f: the trim() function is not a FORTRAN 77 function. It was > introduced in Fortran 90. (This does not show up when you use an F90 > compiler - sigh) > > I will look into this one. > > Regards, > > Arjen > > On 2009-03-19 22:08, Werner Smekal wrote: >> Hi Arjen, >>>> >>> Well, the cause of the problem is clear now: when linking the >>> Fortran >>> bindings >>> into a DLL, gfortran would need the option -Wl,-out-implib,... (or >>> something >>> similar) to produce the missing library. >>> >>> This option _is_ present in the gcc part to create the DLL >>> libplplotf77cd.dll. >> I revisited this problem, since it still exists and wanted at least >> to >> make it work. >>> >>> I checked to see if I could easily add it, but I have not found a >>> specific CMake >>> module for gfortran under Windows. >> I tried to change the Windows-g77.cmake module but was not >> successful in >> adding this -Wl,-out-implib - I think this is maybe not possible, >> since >> there is no Fortran statement to export a symbol. I tried to add >> a .def >> file, but also no success. >>> >>> So my question now is: Should I go ahead and add such module for >>> this >>> particular >>> combination (as part of general modules) or add it to the >>> CMakeLists.txt file as >>> a special case. Or is there another way I should proceed? >>> >>> More details on the platform: >>> - I am running CMake in an ordinary DOS-box under Windows XP. >>> - I make sure that gcc and gfortran are in the path, so that CMake >>> will pick up >>> these compilers. >>> - I use the "MinGW Makefiles" output option to generate the >>> makefiles. >>> >>> (This differs from the situation where I run CMake via MSYS. MSYS >>> and >>> MinGW are explicitly distinguished in the CMake modules, but I am >>> not >>> sure how the above situation is characterised) >> I added now a custom post-build target, which runs dlltool to >> create the >> import library. Works great so far. Arjen, could you test that. Only >> implemented for f77 so far, f95 would be straight forward. If we >> manage >> to improve the cmake files we can remove it again. >> >> Example 23 doesn't compile now. I get the following message: >> >> [ 77%] Building Fortran object examples/f77/CMakeFiles/x23f.dir/ >> x23f.f.obj >> Z:\DevZone\PLdev\build\gcc\debug\examples\f77\x23f.f: In program >> `x23f': >> Z:\DevZone\PLdev\build\gcc\debug\examples\f77\x23f.f:320: warning: >> & trim(family(ifamily+1))//' '//trim(style(istyle+1))//' >> '// >> ^ >> Reference to unimplemented intrinsic `TRIM' at (^) (assumed EXTERNAL) >> Z:\DevZone\PLdev\build\gcc\debug\examples\f77\x23f.f:320: >> & trim(family(ifamily+1))//' '//trim(style(istyle+1))//' >> '// >> ^ >> Invalid declaration of or reference to symbol `trim' at (^) >> [initially >> seen at (^)] >> mingw32-make[2]: *** [examples/f77/CMakeFiles/x23f.dir/x23f.f.obj] >> Error 1 >> mingw32-make[1]: *** [examples/f77/CMakeFiles/x23f.dir/all] Error 2 >> mingw32-make: *** [all] Error 2 >> >> My Fortran knowledge is not very exhaustive. Any ideas? >> >> Best Regards, >> Werner >>> >>> Regards, >>> >>> Arjen >>> >>> ------------------------------------------------------------------------ >>> >>> ------------------------------------------------------------------------- >>> This SF.Net email is sponsored by the Moblin Your Move Developer's >>> challenge >>> Build the coolest Linux based applications with Moblin SDK & win >>> great >>> prizes >>> Grand prize is a trip for two to an Open Source event anywhere in >>> the >>> world >>> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Plplot-devel mailing list >>> Plp...@li... >>> https://lists.sourceforge.net/lists/listinfo/plplot-devel >>> >> >> > > > 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. > > > > > > ------------------------------------------------------------------------------ > Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) > are > powering Web 2.0 with engaging, cross-platform capabilities. Quickly > and > easily build your RIAs with Flex Builder, the Eclipse(TM)based > development > software that enables intelligent coding and step-through debugging. > Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > 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: sm...@ia... 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 |
From: Arjen M. <arj...@de...> - 2009-03-24 08:42:21
|
Hi Werner, the def-file is a file with instructions for the linker, so as far as CMake is concerned, it has the same function as a source file. I am not sure why it works for me and not for you (right now, it is not part of the dependencies - we need to take a look at that). This requires further investigation: - I will write down the steps I take and the precise CMake options - I will experiment with various combinations of static and dynamic options. I am not sure if I can do that tonight - I will have to see, but it is surely puzzling! Regards, Arjen On 2009-03-24 09:34, Werner Smekal wrote: > Hi Arjen, >> > >> right, my Fortran compiler is usually gfortran or g95 - g77 is a very >> old compiler that is no longer actively maintained. I can imagine >> that the compiler does not produce import libraries - shared libraries >> under Windows simply have too many pecularities, so they are probably >> beyond g77's capabilities. dlltool is the way forward here. > > What I don't understand is, why it works for you (gfortran), since with > MinGW 4.3.2 and gfortran 4.3.2 I have the same problems (no import > library). In the CMakeLists.txt (for both f77 and f95) we add a .def file > > if(WIN32 AND BUILD_SHARED_LIBS AND NOT MINGW) > SET(plplotf95${LIB_TAG}_LIB_SRCS ${plplotf95${LIB_TAG}_LIB_SRCS} > plplotf95.def) > endif(WIN32 AND BUILD_SHARED_LIBS AND NOT MINGW) > > What is cmake supposed to do with this file? If you add the .def file, > does CMake automatically create a import library? For which compiler? If > I do this for the MinGW compiler no import library is created. I > understand that Fortran doesn't provide this dllimport/dllexport > keywords and you need to create the import library later. But does that > work for other compilers? > > And why does it work for you? If there is a case where it works for > gfortran we need to alter the cmake files. > > In the moment it works for my compiler toolset (MinGW/g77 and > MinGW/gfortran), but we should test that for other combinations as well. > > Thanks, > Werner > > > >> >> As to x23f: the trim() function is not a FORTRAN 77 function. It was >> introduced in Fortran 90. (This does not show up when you use an F90 >> compiler - sigh) >> >> I will look into this one. >> >> Regards, >> >> Arjen >> >> On 2009-03-19 22:08, Werner Smekal wrote: >>> Hi Arjen, >>>>> >>>> Well, the cause of the problem is clear now: when linking the Fortran >>>> bindings >>>> into a DLL, gfortran would need the option -Wl,-out-implib,... (or >>>> something >>>> similar) to produce the missing library. >>>> >>>> This option _is_ present in the gcc part to create the DLL >>>> libplplotf77cd.dll. >>> I revisited this problem, since it still exists and wanted at least to >>> make it work. >>>> >>>> I checked to see if I could easily add it, but I have not found a >>>> specific CMake >>>> module for gfortran under Windows. >>> I tried to change the Windows-g77.cmake module but was not successful in >>> adding this -Wl,-out-implib - I think this is maybe not possible, since >>> there is no Fortran statement to export a symbol. I tried to add a .def >>> file, but also no success. >>>> >>>> So my question now is: Should I go ahead and add such module for this >>>> particular >>>> combination (as part of general modules) or add it to the >>>> CMakeLists.txt file as >>>> a special case. Or is there another way I should proceed? >>>> >>>> More details on the platform: >>>> - I am running CMake in an ordinary DOS-box under Windows XP. >>>> - I make sure that gcc and gfortran are in the path, so that CMake >>>> will pick up >>>> these compilers. >>>> - I use the "MinGW Makefiles" output option to generate the makefiles. >>>> >>>> (This differs from the situation where I run CMake via MSYS. MSYS and >>>> MinGW are explicitly distinguished in the CMake modules, but I am not >>>> sure how the above situation is characterised) >>> I added now a custom post-build target, which runs dlltool to create the >>> import library. Works great so far. Arjen, could you test that. Only >>> implemented for f77 so far, f95 would be straight forward. If we manage >>> to improve the cmake files we can remove it again. >>> >>> Example 23 doesn't compile now. I get the following message: >>> >>> [ 77%] Building Fortran object >>> examples/f77/CMakeFiles/x23f.dir/x23f.f.obj >>> Z:\DevZone\PLdev\build\gcc\debug\examples\f77\x23f.f: In program `x23f': >>> Z:\DevZone\PLdev\build\gcc\debug\examples\f77\x23f.f:320: warning: >>> & trim(family(ifamily+1))//' '//trim(style(istyle+1))//' '// >>> ^ >>> Reference to unimplemented intrinsic `TRIM' at (^) (assumed EXTERNAL) >>> Z:\DevZone\PLdev\build\gcc\debug\examples\f77\x23f.f:320: >>> & trim(family(ifamily+1))//' '//trim(style(istyle+1))//' '// >>> ^ >>> Invalid declaration of or reference to symbol `trim' at (^) [initially >>> seen at (^)] >>> mingw32-make[2]: *** [examples/f77/CMakeFiles/x23f.dir/x23f.f.obj] >>> Error 1 >>> mingw32-make[1]: *** [examples/f77/CMakeFiles/x23f.dir/all] Error 2 >>> mingw32-make: *** [all] Error 2 >>> >>> My Fortran knowledge is not very exhaustive. Any ideas? >>> >>> Best Regards, >>> Werner >>>> >>>> Regards, >>>> >>>> Arjen >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> >>>> ------------------------------------------------------------------------- >>>> >>>> This SF.Net email is sponsored by the Moblin Your Move Developer's >>>> challenge >>>> Build the coolest Linux based applications with Moblin SDK & win great >>>> prizes >>>> Grand prize is a trip for two to an Open Source event anywhere in the >>>> world >>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >>>> ------------------------------------------------------------------------ >>>> >>>> >>>> _______________________________________________ >>>> Plplot-devel mailing list >>>> Plp...@li... >>>> https://lists.sourceforge.net/lists/listinfo/plplot-devel >>>> >>> >>> >> >> >> 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. >> >> >> >> >> >> ------------------------------------------------------------------------------ >> >> Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are >> powering Web 2.0 with engaging, cross-platform capabilities. Quickly and >> easily build your RIAs with Flex Builder, the Eclipse(TM)based >> development >> software that enables intelligent coding and step-through debugging. >> Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com >> _______________________________________________ >> Plplot-devel mailing list >> Plp...@li... >> 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: sm...@ia... > 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. |
From: Alan W. I. <ir...@be...> - 2009-03-20 01:46:31
|
On 2009-03-19 22:08+0100 Werner Smekal wrote: > Example 23 doesn't compile now. I get the following message: > > [ 77%] Building Fortran object examples/f77/CMakeFiles/x23f.dir/x23f.f.obj > Z:\DevZone\PLdev\build\gcc\debug\examples\f77\x23f.f: In program `x23f': > Z:\DevZone\PLdev\build\gcc\debug\examples\f77\x23f.f:320: warning: > & trim(family(ifamily+1))//' '//trim(style(istyle+1))//' '// > ^ > Reference to unimplemented intrinsic `TRIM' at (^) (assumed EXTERNAL) > Z:\DevZone\PLdev\build\gcc\debug\examples\f77\x23f.f:320: > & trim(family(ifamily+1))//' '//trim(style(istyle+1))//' '// > ^ > Invalid declaration of or reference to symbol `trim' at (^) [initially > seen at (^)] > mingw32-make[2]: *** [examples/f77/CMakeFiles/x23f.dir/x23f.f.obj] Error 1 > mingw32-make[1]: *** [examples/f77/CMakeFiles/x23f.dir/all] Error 2 > mingw32-make: *** [all] Error 2 > > My Fortran knowledge is not very exhaustive. Any ideas? "trim" is recognized by the gfortran compiler (at least the version of it that I have), but not g77 (which I believe is what you still must use with MinGW). Our other f77 examples use lnblnk instead of trim and apparently you (and anybody else who has tested our f77 examples) had no trouble with that. Therefore, I have (revision 9761) updated examples 23 and 31 (the ones that were using trim) to use lnblnk instead of trim. Does that revision work for you? 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...> - 2009-03-20 07:45:35
|
Hello Alan, For MinGW we also have g95 and gfortran available. But it can't hurt to test with a FORTRAN 77 compiler perse. Regards, Arjen On 2009-03-20 02:31, Alan W. Irwin wrote: > > "trim" is recognized by the gfortran compiler (at least the version of it > that I have), but not g77 (which I believe is what you still must use with > MinGW). Our other f77 examples use lnblnk instead of trim and apparently > you (and anybody else who has tested our f77 examples) had no trouble with > that. Therefore, I have (revision 9761) updated examples 23 and 31 (the > ones that were using trim) to use lnblnk instead of trim. 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. |
From: Werner S. <sm...@ia...> - 2009-03-24 08:28:12
|
Hi Alan, > "trim" is recognized by the gfortran compiler (at least the version > of it > that I have), but not g77 (which I believe is what you still must > use with > MinGW). Our other f77 examples use lnblnk instead of trim and > apparently > you (and anybody else who has tested our f77 examples) had no > trouble with > that. Therefore, I have (revision 9761) updated examples 23 and 31 > (the > ones that were using trim) to use lnblnk instead of trim. > > Does that revision work for you? Yes, the examples (f77 for MinGW 3.4.5 and 4.3.2 and f95 for MinGW 4.3.2) compile now (though they don't run). Regards, Werner > > 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 > __________________________ > > ------------------------------------------------------------------------------ > Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) > are > powering Web 2.0 with engaging, cross-platform capabilities. Quickly > and > easily build your RIAs with Flex Builder, the Eclipse(TM)based > development > software that enables intelligent coding and step-through debugging. > Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > 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: sm...@ia... 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 |
From: Arjen M. <arj...@de...> - 2009-03-24 08:31:36
|
Hi Werner, what is the reason they do not run? If you do not get any output, the program simply stops, that could be due to a missing DLL (sometimes you get a message, sometimes you don't under Windows). Regards, Arjen On 2009-03-24 09:27, Werner Smekal wrote: > Hi Alan, > >> "trim" is recognized by the gfortran compiler (at least the version of it >> that I have), but not g77 (which I believe is what you still must use >> with >> MinGW). Our other f77 examples use lnblnk instead of trim and apparently >> you (and anybody else who has tested our f77 examples) had no trouble >> with >> that. Therefore, I have (revision 9761) updated examples 23 and 31 (the >> ones that were using trim) to use lnblnk instead of trim. >> >> Does that revision work for you? > > Yes, the examples (f77 for MinGW 3.4.5 and 4.3.2 and f95 for MinGW > 4.3.2) compile now (though they don't run). > > Regards, > Werner > >> >> 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 >> __________________________ >> >> ------------------------------------------------------------------------------ >> >> Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are >> powering Web 2.0 with engaging, cross-platform capabilities. Quickly and >> easily build your RIAs with Flex Builder, the Eclipse(TM)based >> development >> software that enables intelligent coding and step-through debugging. >> Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com >> _______________________________________________ >> Plplot-devel mailing list >> Plp...@li... >> 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: sm...@ia... > 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. |
From: Werner S. <sm...@ia...> - 2009-03-24 08:38:17
|
Hi, I'm using the dynamic drivers and it exits with a message like (translated from German): "The application could not be started, since (null).dll wasn't found. A new installation of the application might solve the problem." Some problem converting C to Fortran strings? Regards, Werner On 24.03.2009, at 09:31, Arjen Markus wrote: > Hi Werner, > > what is the reason they do not run? If you do not get any output, > the program simply stops, that could be due to a missing DLL > (sometimes > you get a message, sometimes you don't under Windows). > > Regards, > > Arjen > > On 2009-03-24 09:27, Werner Smekal wrote: >> Hi Alan, >> >>> "trim" is recognized by the gfortran compiler (at least the >>> version of it >>> that I have), but not g77 (which I believe is what you still must >>> use >>> with >>> MinGW). Our other f77 examples use lnblnk instead of trim and >>> apparently >>> you (and anybody else who has tested our f77 examples) had no >>> trouble >>> with >>> that. Therefore, I have (revision 9761) updated examples 23 and >>> 31 (the >>> ones that were using trim) to use lnblnk instead of trim. >>> >>> Does that revision work for you? >> >> Yes, the examples (f77 for MinGW 3.4.5 and 4.3.2 and f95 for MinGW >> 4.3.2) compile now (though they don't run). >> >> Regards, >> Werner >> >>> >>> 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 >>> __________________________ >>> >>> ------------------------------------------------------------------------------ >>> >>> Apps built with the Adobe(R) Flex(R) framework and Flex >>> Builder(TM) are >>> powering Web 2.0 with engaging, cross-platform capabilities. >>> Quickly and >>> easily build your RIAs with Flex Builder, the Eclipse(TM)based >>> development >>> software that enables intelligent coding and step-through debugging. >>> Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com >>> _______________________________________________ >>> Plplot-devel mailing list >>> Plp...@li... >>> 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: sm...@ia... >> 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. > > > > > > ------------------------------------------------------------------------------ > Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) > are > powering Web 2.0 with engaging, cross-platform capabilities. Quickly > and > easily build your RIAs with Flex Builder, the Eclipse(TM)based > development > software that enables intelligent coding and step-through debugging. > Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > 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: sm...@ia... 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 |
From: Arjen M. <arj...@de...> - 2009-03-24 08:43:56
|
On 2009-03-24 09:38, Werner Smekal wrote: > Hi, > > I'm using the dynamic drivers and it exits with a message like > (translated from German): > > "The application could not be started, since (null).dll wasn't found. A > new installation of the application might solve the problem." > > Some problem converting C to Fortran strings? > Hi Werner, I can not imagine that that is the case! Such messages are typically produced by the run-time and system libraries. The (null) is very suspcious though - I have never seen it before. Could it be the compilers in your MinGW environment? 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. |
From: Werner S. <sm...@ia...> - 2009-03-24 08:52:09
|
Hi Arjen, > > On 2009-03-24 09:38, Werner Smekal wrote: >> Hi, >> >> I'm using the dynamic drivers and it exits with a message like >> (translated from German): >> >> "The application could not be started, since (null).dll wasn't >> found. A >> new installation of the application might solve the problem." >> >> Some problem converting C to Fortran strings? >> > > Hi Werner, > > I can not imagine that that is the case! Such messages are typically > produced by the run-time and system libraries. The (null) is very > suspcious though - I have never seen it before. > > Could it be the compilers in your MinGW environment? The MinGW 3.4.5 toolset is the official one from mingw.org. The 4.3.3 MinGW toolset is taken from http://www.tdragon.net/recentgcc/ which is unofficial bot know to work. Since both compilers have the exactly same problem I don't assume that the compiler toolset are the problem. I'm using the Windows CLI though and not MSYS. 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. > > > > > > ------------------------------------------------------------------------------ > Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) > are > powering Web 2.0 with engaging, cross-platform capabilities. Quickly > and > easily build your RIAs with Flex Builder, the Eclipse(TM)based > development > software that enables intelligent coding and step-through debugging. > Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > 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: sm...@ia... 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 |
From: Arjen M. <arj...@de...> - 2009-03-27 09:15:53
|
Hi Werner, I have run into a problem with dlltool: is that still required in your case? I run into it, because my rather basic installation of MinGW does not have it (the tdragon one): make/cmake complains about an unknown tool. Regards, Arjen On 2009-03-24 09:51, Werner Smekal wrote: > Hi Arjen, >> >> On 2009-03-24 09:38, Werner Smekal wrote: >>> Hi, >>> >>> I'm using the dynamic drivers and it exits with a message like >>> (translated from German): >>> >>> "The application could not be started, since (null).dll wasn't found. A >>> new installation of the application might solve the problem." >>> >>> Some problem converting C to Fortran strings? >>> >> >> Hi Werner, >> >> I can not imagine that that is the case! Such messages are typically >> produced by the run-time and system libraries. The (null) is very >> suspcious though - I have never seen it before. >> >> Could it be the compilers in your MinGW environment? > > The MinGW 3.4.5 toolset is the official one from mingw.org. The 4.3.3 > MinGW toolset is taken from http://www.tdragon.net/recentgcc/ which is > unofficial bot know to work. Since both compilers have the exactly same > problem I don't assume that the compiler toolset are the problem. I'm > using the Windows CLI though and not MSYS. > > 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. >> >> >> >> >> >> ------------------------------------------------------------------------------ >> >> Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are >> powering Web 2.0 with engaging, cross-platform capabilities. Quickly and >> easily build your RIAs with Flex Builder, the Eclipse(TM)based >> development >> software that enables intelligent coding and step-through debugging. >> Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com >> _______________________________________________ >> Plplot-devel mailing list >> Plp...@li... >> 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: sm...@ia... > 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. |
From: Werner S. <sm...@ia...> - 2009-03-27 09:20:18
|
Hi Arjen, I need dlltool to create the import libraries, otherwise they are not created (for me). You could comment it in bindings/f77/CMakeList.txt and see if for you the import libraries are created. But then: why for you and not for me? Regards, Werner On 27.03.2009, at 10:15, Arjen Markus wrote: > Hi Werner, > > I have run into a problem with dlltool: is that still required in your > case? I run into it, because my rather basic installation of MinGW > does not have it (the tdragon one): make/cmake complains about an > unknown tool. > > Regards, > > Arjen > > On 2009-03-24 09:51, Werner Smekal wrote: >> Hi Arjen, >>> >>> On 2009-03-24 09:38, Werner Smekal wrote: >>>> Hi, >>>> >>>> I'm using the dynamic drivers and it exits with a message like >>>> (translated from German): >>>> >>>> "The application could not be started, since (null).dll wasn't >>>> found. A >>>> new installation of the application might solve the problem." >>>> >>>> Some problem converting C to Fortran strings? >>>> >>> >>> Hi Werner, >>> >>> I can not imagine that that is the case! Such messages are typically >>> produced by the run-time and system libraries. The (null) is very >>> suspcious though - I have never seen it before. >>> >>> Could it be the compilers in your MinGW environment? >> >> The MinGW 3.4.5 toolset is the official one from mingw.org. The 4.3.3 >> MinGW toolset is taken from http://www.tdragon.net/recentgcc/ which >> is >> unofficial bot know to work. Since both compilers have the exactly >> same >> problem I don't assume that the compiler toolset are the problem. I'm >> using the Windows CLI though and not MSYS. >> >> 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. >>> >>> >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> >>> Apps built with the Adobe(R) Flex(R) framework and Flex >>> Builder(TM) are >>> powering Web 2.0 with engaging, cross-platform capabilities. >>> Quickly and >>> easily build your RIAs with Flex Builder, the Eclipse(TM)based >>> development >>> software that enables intelligent coding and step-through debugging. >>> Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com >>> _______________________________________________ >>> Plplot-devel mailing list >>> Plp...@li... >>> 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: sm...@ia... >> 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 > Plp...@li... > 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: sm...@ia... 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 |
From: Arjen M. <arj...@de...> - 2009-03-27 09:21:26
|
On 2009-03-27 10:20, Werner Smekal wrote: > Hi Arjen, > > I need dlltool to create the import libraries, otherwise they are not > created (for me). You could comment it in bindings/f77/CMakeList.txt and > see if for you the import libraries are created. But then: why for you > and not for me? > Hi Werner, yes, this remains a nasty riddle! We'll need to compare versions I guess. 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. |