From: Arjen M. <arj...@de...> - 2009-04-29 11:35:14
|
Hello, I want to report the results from a few tests regarding the next release. So far I have tested the following platforms: 1. Cygwin: shared library + dynamic drivers 2. Cygwin: static library + static drivers 3. Bare Windows: shared library + dynamic drivers ad 1. General: CMake under Cygwin requires that you set the environment variable CMAKE_ROOT, also when running make. (I need to make a note in the installation documentation for that.) There is a problem with the shared l'ibraries that are produced during the build: you need to set the path right. Unfortunately this includes _all_ paths: lib/csa, lib/nistcd, lib/qsastime, src, drivers, bindings/c++, etc. I tried to use the LIBRARY_OUTPUT_PATH variable in the toplevel CMakeLists.txt file, but that failed: libtool can not find the driver DLLs then. (We need to sort this one out!) Tests: None done, because of the above issues. ad 2. General: Set CMAKE_ROOT Tests: Testing the Tcl examples fails - you need to set TCL_LIBRARY so that the custom shell can find the initialisation files (init.tcl etc.) Testing of C, C++, F77 and F95 worked fine. There are however differences for examples 15 and 20. ad 3. General: Extend the path with the directory containing the ...\dll subdirectory (use the complete path to be sure; add to/check the installation notes). Fortran: For some reason the export definition files were not taken into account when linking. I restored that feature - strictly for "bare Windows". Otherwise the link step fails! Tests: Tcl fails again - presumably also on TCL_LIBRARY. I had a failure in example x19f (F95), due to a difference in calling conventions (the mapform function that is passed). This led to a couple of changes, but it all works again. Differences for examples 14, 15 and 20. (Other platforms remain to be done: MSYS and MinGW) 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: Arjen M. <arj...@de...> - 2009-05-01 12:48:19
|
On 2009-04-29 13:34, Arjen Markus wrote: > > There is a problem with the shared l'ibraries that are produced during > the build: you need to set the path right. Unfortunately this includes > _all_ paths: lib/csa, lib/nistcd, lib/qsastime, src, drivers, > bindings/c++, etc. > > I tried to use the LIBRARY_OUTPUT_PATH variable in the toplevel > CMakeLists.txt file, but that failed: libtool can not find the driver > DLLs then. > > (We need to sort this one out!) > Does anyone have an idea on how to solve this issue? I could revert to Werner's Windows-specific libtool look-a-like for all Windows builds, but that may be a rather big step just before a release. 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-05-01 15:22:25
|
Hi Arjen, Arjen Markus wrote: > On 2009-04-29 13:34, Arjen Markus wrote: > > >> There is a problem with the shared l'ibraries that are produced during >> the build: you need to set the path right. Unfortunately this includes >> _all_ paths: lib/csa, lib/nistcd, lib/qsastime, src, drivers, >> bindings/c++, etc. >> >> I tried to use the LIBRARY_OUTPUT_PATH variable in the toplevel >> CMakeLists.txt file, but that failed: libtool can not find the driver >> DLLs then. >> >> (We need to sort this one out!) >> >> > > Does anyone have an idea on how to solve this issue? I could revert > to Werner's Windows-specific libtool look-a-like for all Windows > builds, but that may be a rather big step just before a release. > Problem is/was that for the original libltdl implementation a path to the driver directory was added in front of the driver name. So the driver wasn't found if all dlls where located in the dll directory. I made a small change to test-drv-info.c and plcore.c which doesn't prepend the path also for cygwin now. Together with the LIBRARY_OUTPUT_PATH correctly set (what do you mean that you tried to use that? It's already there isn't it: # in windows all created dlls are gathered in the dll directory # if you add this directory to your PATH all shared libraries are available if(BUILD_SHARED_LIBS AND WIN32) SET(LIBRARY_OUTPUT_PATH ${CMAKE_CURRENT_BINARY_DIR}/dll) endif(BUILD_SHARED_LIBS AND WIN32) (line 108-112). This is also in the svn, so you shouldn't need to change that. ) and if you add the dll directory to the PATH environment variable this should make the dynamic drivers work for Cygwin. At least it works for me now. Could you please test that? Thanks, 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. > > > > > > ------------------------------------------------------------------------------ > Register Now & Save for Velocity, the Web Performance & Operations > Conference from O'Reilly Media. Velocity features a full day of > expert-led, hands-on workshops and two days of sessions from industry > leaders in dedicated Performance & Operations tracks. Use code vel09scf > and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf > _______________________________________________ > 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-05-01 16:43:52
|
On Fri, 01 May 2009 17:22:09 +0200 Werner Smekal <sm...@ia...> wrote: > Hi Arjen, > >> > Problem is/was that for the original libltdl >implementation a path to the driver directory was added >in front of the driver name. So the driver wasn't found >if all dlls where located in the dll directory. I made a >small change to test-drv-info.c and plcore.c which >doesn't prepend the path also for cygwin now. Together >with the LIBRARY_OUTPUT_PATH correctly set (what do you >mean that you tried to use that? It's already there isn't >it: > > # in windows all created dlls are gathered in the dll >directory > # if you add this directory to your PATH all shared >libraries are available > if(BUILD_SHARED_LIBS AND WIN32) > SET(LIBRARY_OUTPUT_PATH >${CMAKE_CURRENT_BINARY_DIR}/dll) > endif(BUILD_SHARED_LIBS AND WIN32) > > (line 108-112). This is also in the svn, so you >shouldn't need to change that. ) > > and if you add the dll directory to the PATH environment >variable this should make the dynamic drivers work for >Cygwin. At least it works for me now. > > Could you please test that? > Hi Werner, ah, that was the reason for libtool to fail. As for CMAKE_OUTPUT_PATH: in my version there was still a condition NOT CYGWIN. When I removed that, libtool failed to load the DLLs. I will try it with this new version. Meanwhile, my tests with MinGW give somewhat mixed results: - Making the pkgIndex.tcl file failed at first on a syntax error, but when I tried to reproduce it (now having winbash in the path for testing), it worked. - Running x16af for either F77 or F95 fails - the message when running x16af manually is: x16af -dev wingcc plparseopts: negative number of arguments So that is the ancient problem again :( - Running them interactively works fine, though. I will let you all know about Cygwin and MSYS - no more time today. 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: Arjen M. <arj...@de...> - 2009-05-02 07:19:04
|
On Fri, 01 May 2009 17:43:44 +0100 Arjen Markus <arj...@de...> wrote: > I will let you all know about Cygwin and MSYS - no more > time today. > Hello Werner, I updated the whole project just now to make sure I have the most up-to-date code and then tried to build it under Cygwin. I am getting an error 53 now when running the nistcd test programs. No idea why - there is no number 53 as such anywhere in the code. 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-05-02 10:47:19
|
Hi Arjen, Arjen Markus wrote: > On Fri, 01 May 2009 17:43:44 +0100 > Arjen Markus <arj...@de...> wrote: >> I will let you all know about Cygwin and MSYS - no more >> time today. >> > > Hello Werner, > > I updated the whole project just now to make sure > I have the most up-to-date code and then tried to > build it under Cygwin. > > I am getting an error 53 now when running the nistcd > test programs. No idea why - there is no number 53 as > such anywhere in the code. Had the same problem yesterday - you need to add the dll directory to the PATH environment variable. 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. > > > > -- 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-05-02 12:56:34
|
On Sat, 02 May 2009 12:46:54 +0200 Werner Smekal <sm...@ia...> wrote: >> >> I am getting an error 53 now when running the nistcd >> test programs. No idea why - there is no number 53 as >> such anywhere in the code. > > Had the same problem yesterday - you need to add the dll >directory to the PATH environment variable. > I thought I had done that, but apparently I made some typo - and then I got very puzzling error messages about a program that was not found, after which family life kicked in ... Retrying and it seems to work better - now let us see what the tests give me. 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: Arjen M. <arj...@de...> - 2009-05-02 13:25:03
|
On Sat, 02 May 2009 14:56:28 +0200 Arjen Markus <arj...@de...> wrote: > > Retrying and it seems to work better - now let us see > what the tests give me. > Hm, the Fortran examples stumble over the same problem as with MinGW: a negative number of arguments, so they turn to interactive mode, hindering the automatic test. Everything builds fine now, though. 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: Alan W. I. <ir...@be...> - 2009-05-02 16:18:25
|
On 2009-05-02 15:24+0200 Arjen Markus wrote: > On Sat, 02 May 2009 14:56:28 +0200 > Arjen Markus <arj...@de...> wrote: >> >> Retrying and it seems to work better - now let us see >> what the tests give me. >> > > Hm, the Fortran examples stumble over the same problem > as with MinGW: a negative number of arguments, so they > turn to interactive mode, hindering the automatic test. Arjen, you appear to be reporting this issue as a new problem. I would be quite surprised if you don't remember you ran into this Cygwin g77 issue years ago, and we implemented what should still be a good workaround then. Therefore, I have a number of questions in response to what you said above: * What fortran compiler on Cygwin? The original issue occurred for the Cygwin version of g77, and the Cygwin maintainers of that package seemed completely unable to fix it because larger issues were involved. I have forgotten the details, but my impression then was they would never be able to fix Cygwin's version of g77. Have you tried gfortran on Cygwin instead? A search on the Cygwin package list (http://cygwin.com/cgi-bin2/package-grep.cgi?grep=gfortran) shows lots of hits. * When you did your MinGW test were you inadvertently using g77 from Cygwin rather than the MinGW version of g77 (or MinGW version of gfortran)? Using an incorrect version of g77 might explain the different results you seem to be getting from Werner. * Even if our build-system test of the Fortran compiler shows its ability to deal with the command-line is broken (as well-known for the Cygwin version of g77) our test scripts have a workaround that should handle that case without issues. Could you expand on what you meant when you referred above to "hindering the automatic test". 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-05-04 07:12:51
|
On 2009-05-02 18:18, Alan W. Irwin wrote: > > Arjen, you appear to be reporting this issue as a new problem. I would be > quite surprised if you don't remember you ran into this Cygwin g77 issue > years ago, and we implemented what should still be a good workaround then. > Hi Alan, I remember that quite well! I was puzzled by its resurfacing at first, but I do have a reasonable explanation: - The current CMake-based build system puts the Fortran bindings in two separate libraries - either static or dynamic libraries. The workaround consists of leaving the routine plparseopts in a separate object file, to be compiled without the -shared option. - Up to a few months ago, I did not have winbash, so ctest was not a useful option to me. Thanks to Werner I can now run ctest for all Windows platforms too and that revealed this issue. - The reason it exists at all is - if I understand it correctly - akin to an issue I raised on comp.lang.fortran some while back (see: http://groups.google.com/group/comp.lang.fortran/browse_frm/thread/5491040da0af22cb?hl=nl#) There seems to be a fundamental difference between DLLs on Windows and shared objects on Linux wrt accessing global data. At least that would explain why information from the main program (command-line arguments and opened files) are not automatically passed on to the DLL. > Therefore, I have a number of questions in response to what you said above: > > * What fortran compiler on Cygwin? The original issue occurred for the > Cygwin version of g77, and the Cygwin maintainers of that package seemed > completely unable to fix it because larger issues were involved. I have > forgotten the details, but my impression then was they would never be able > to fix Cygwin's version of g77. Have you tried gfortran on Cygwin instead? > A search on the Cygwin package list > (http://cygwin.com/cgi-bin2/package-grep.cgi?grep=gfortran) shows lots of > hits. > For Cygwin I use the gfortran version that comes with it (gfortran is preferred over g77 by CMake and the issue arose with the Fortran 95 examples as well). > * When you did your MinGW test were you inadvertently using g77 from Cygwin > rather than the MinGW version of g77 (or MinGW version of gfortran)? Using > an incorrect version of g77 might explain the different results you seem to > be getting from Werner. > Nope, for MinGW I explicitly use the gfortran version from "TDM". I never installed a g77 version for that (I run outside MSYS, which may have that, but I doubt it). > * Even if our build-system test of the Fortran compiler shows its > ability to > deal with the command-line is broken (as well-known for the Cygwin version > of g77) our test scripts have a workaround that should handle that case > without issues. Could you expand on what you meant when you referred above > to "hindering the automatic test". > What happens is that the test scripts start, proceed with C and C++ and then "hang": there is no progress anymore. Checking the processes that are running I then find that x16af is waiting. If I run x16af with -dev wingcc manually, I get the message about a negative number of arguments and then the list of available drivers. I did not want to experiment with a set-up where configurable.obj is put in a static library of its own so short before the release. This is definitely something for the coming few days though. (Another experiment is: try it in a small test program) 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: Arjen M. <arj...@de...> - 2009-05-04 11:46:38
|
On 2009-05-02 18:18, Alan W. Irwin wrote: > > Arjen, you appear to be reporting this issue as a new problem. I would be > quite surprised if you don't remember you ran into this Cygwin g77 issue > years ago, and we implemented what should still be a good workaround then. > Hi Alan, I have just confirmed this issue with a small program, using gfortran version 4.4. I have sent a message to the gfortran list about it. 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. |