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. ------------------------------------------------------------------------------ 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 Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
