From: Arjen M. <arj...@de...> - 2011-11-09 12:00:01
|
Hello, I have run into a strange problem with the Fortran 95 bindings. My platform is Windows XP (using MinGW, not MSYS) with gfortran as the Fortran compiler. The Fortran 77 bindings and examples work fine with that combination, but gfortran refuses to build the Fortran 95 examples. The reason is that there are duplicate symbols, such as _gfortran_set_args, that the linker does not like. Strangely enough, these symbols are referred to in libplplotf95d.dll.a and libplplotf95optsd.a as well as libplplotf77optsd.a (I expect them in the latter two), but not in the Fortran 77 library libplplotf77d.dll.a. Their absence in that last file means that the linker finds only one definition and is perfectly happy building the examples. I have tried to deduce from the object files and compile options and the like where the difference is coming from, but without a single piece of success. My solution therefore is to bring in the option "-Wl,--allow-multiplpe-define", as with that option linking the examples does work. Has anyone seen similar problems on this or another platform? Regards, Arjen 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...> - 2011-11-09 18:19:25
|
Hi Arjen: On 2011-11-09 12:59+0100 Arjen Markus wrote: > Hello, > > I have run into a strange problem with the Fortran 95 bindings. > My platform is Windows XP (using MinGW, not MSYS) with gfortran as the > Fortran compiler. The Fortran 77 bindings and examples work fine with > that combination, but gfortran refuses to build the Fortran 95 examples. > The reason is that there are duplicate symbols, such as > _gfortran_set_args, that the linker does not like. > > Strangely enough, these symbols are referred to in libplplotf95d.dll.a > and libplplotf95optsd.a as well as libplplotf77optsd.a (I expect them in > the latter two), but not in the Fortran 77 library libplplotf77d.dll.a. > Their absence in that last file means that the linker finds only one > definition and is perfectly happy building the examples. > > I have tried to deduce from the object files and compile options and > the like where the difference is coming from, but without a single > piece of success. > > My solution therefore is to bring in the option > "-Wl,--allow-multiplpe-define", as with that option linking the > examples does work. > > Has anyone seen similar problems on this or another platform? Hi Arjen: Is this the first time you have tested the MinGW version of gfortran on Windows for our f95 examples using the "MinGw Makefiles" generator? As I recall, I could not get those examples to work on MinGW/Wine for the "MSYS Makefiles" generator, but I believe it was a separate issue (complaints about the form of the module file). I wrote that off as a Wine platform problem and probably didn't get deep enough into the testing to run into the problem you describe. What happens for the "MSYS Makefiles" generator? This will test if the issue is specific to the "MinGW Makefiles" generator or more general. All of the relevant build system logic is controlled with the STATIC_OPTS cmake variable which is set in cmake/modules/TestF77CmdLine.cmake as follows: SET(STATIC OFF) IF(WIN32) IF(MINGW OR CYGWIN) IF(BUILD_SHARED_LIBS) SET(STATIC ON) ENDIF(BUILD_SHARED_LIBS) ENDIF(MINGW OR CYGWIN) ENDIF(WIN32) IF(STATIC) SET(STATIC_OPTS ON CACHE BOOL "Command-line parsing in static library") ELSE(STATIC) SET(STATIC_OPTS OFF CACHE BOOL "Command-line parsing in static library") ENDIF(STATIC) It appears this build system logic is attempting to work around some problem with the MINGW gfortran compiler (for either generator since the MINGW cmake variable is set for the MinGW compiler regardless of generator) for the Windows and Cygwin platforms. A fundamental question is whether that problem has now been fixed for the latest MinGW compiler. To answer that question replace SET(STATIC ON) ==> SET(STATIC OFF) (which implies that STATIC_OPTS will always be OFF) in the above logic; install that latest versions of MinGW/MSYS; and rename sh.exe so the "MinGW Makefiles" generator will work. (That rename allows you to keep bash.exe on your PATH so that all the test suite works for the "MinGW Makefiles" generator just like it does for the "MSYS Makefiles" generator.) Or don't rename she.exe and use the "MSYS Makefiles" generator instead. N.B. you have to download and install the latest automatic installer for MinGW/MSYS to access the latest MinGW/MSYS. Using the update command for an older version of that automatic installer does not get you the latest versions. Even if STATIC_OPTS ON turns out to still be necessary with the latest MinGW and MinGW/MSYS versions of gfortran, I have some questions about the implementation. For the f95 case and STATIC_OPTS ON we have the following cmake logic: add_library(plplotf95${LIB_TAG} ${plplotf95${LIB_TAG}_LIB_SRCS}) if(STATIC_OPTS) add_library(plplotf95opts${LIB_TAG} STATIC ${plplotf95opts${LIB_TAG}_LIB_SRCS}) target_link_libraries(plplotf95${LIB_TAG} plplotf95c${LIB_TAG}) target_link_libraries(plplotf95opts${LIB_TAG} plplotf95${LIB_TAG} plplotf95c${LIB_TAG}) else(STATIC_OPTS) target_link_libraries(plplotf95${LIB_TAG} plplotf95c${LIB_TAG}) endif(STATIC_OPTS) So it appears for the STATIC_OPTS ON case you are trying to link the static plplotf95opts${LIB_TAG} library using the shared plplotf95${LIB_TAG} library as a dependency. Such mixtures of shared and static libraries are always tricky to link correctly. As far as I can tell plplotf95opts${LIB_TAG} only has the plparseopts7_ symbol undefined which is resolved by plplotf95c${LIB_TAG}. In other words, I don't believe plplotf95${LIB_TAG} supplies any symbol required by plplotf95opts${LIB_TAG}. I would think putting plplotf95c${LIB_TAG} in the dependent library list for target_link_libraries(plplotf95opts${LIB_TAG} ....) would be relatively harmless, but there be some nasty linking side effect that is causing so I would suggest simplifying the linking logic as follows for the STATIC_OPTS ON case: add_library(plplotf95opts${LIB_TAG} STATIC ${plplotf95opts${LIB_TAG}_LIB_SRCS}) target_link_libraries(plplotf95${LIB_TAG} plplotf95c${LIB_TAG}) target_link_libraries(plplotf95opts${LIB_TAG} plplotf95c${LIB_TAG}) This simplified linking means that the examples will need to be linked to both plplotf95opts${LIB_TAG} and plplotf95${LIB_TAG} for the STATIC_OPTS ON case, but that is a small price to pay if the result works. There are a number of other possibilities to try such as linking plplotf95opts${LIB_TAG} separately but as SHARED, or linking it STATIC but with the -FPIC compile option so that it can be linked as a dependency of plplotf95${LIB_TAG. But I think your best bets for solving this are (1) install the latest gfortran version available for MinGW and try both the "MinGW Makefiles" and "MSYS Makefiles" generators, or (2) simplify the linking by dropping plplotf95${LIB_TAG} (as above) as a target_link_libraries dependency of plplotf95opts${LIB_TAG}. If none of those options work, I would be willing to try to test the combination of the latest wine and latest MinGW/MSYS under Wine to see if the module issue in that case is now solved so that I can explore the issue under Wine. But that is a pretty big time committment when I am tied up with other things so I really hope one of my suggested options does 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); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); 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...> - 2011-11-10 07:49:53
|
i Alan, On 2011-11-09 19:19, Alan W. Irwin wrote: > > Is this the first time you have tested the MinGW version of gfortran > on Windows for our f95 examples using the "MinGw Makefiles" generator? > As I recall, I could not get those examples to work on MinGW/Wine for > the "MSYS Makefiles" generator, but I believe it was a separate issue > (complaints about the form of the module file). I wrote that off as a > Wine platform problem and probably didn't get deep enough into the > testing to run into the problem you describe. > No, the MinGW+gfortran combination (not MSYS) is the one I use most. It is only very recent that I noticed these issues. The issue is very strange, because I can see no reason in the source code or the object code for including these routines that are part of gfortran run-time. Also note that these routines are not doubly present in the FORTRAN 77 case. It may be the combination of static and dynamic libraries that is causing trouble, but the command-line arguments passed to the program are not accessible from a DLL/shared object. So if we turn to dynamic libraries only, we lose the functionality. > What happens for the "MSYS Makefiles" generator? This will test if > the issue is specific to the "MinGW Makefiles" generator or more > general. Hm, I have not tried that yet. > > All of the relevant build system logic is controlled > with the STATIC_OPTS cmake variable which is set in > cmake/modules/TestF77CmdLine.cmake as follows: > > SET(STATIC OFF) > IF(WIN32) > IF(MINGW OR CYGWIN) > IF(BUILD_SHARED_LIBS) > SET(STATIC ON) > ENDIF(BUILD_SHARED_LIBS) > ENDIF(MINGW OR CYGWIN) > ENDIF(WIN32) > IF(STATIC) > SET(STATIC_OPTS ON CACHE BOOL "Command-line parsing in static library") > ELSE(STATIC) > SET(STATIC_OPTS OFF CACHE BOOL "Command-line parsing in static library") > ENDIF(STATIC) > > It appears this build system logic is attempting to work around some > problem with the MINGW gfortran compiler (for either generator since > the MINGW cmake variable is set for the MinGW compiler regardless of > generator) for the Windows and Cygwin platforms. A fundamental > question is whether that problem has now been fixed for the latest > MinGW compiler. To answer that question replace > > SET(STATIC ON) ==> SET(STATIC OFF) > > (which implies that STATIC_OPTS will always be OFF) in the above > logic; install that latest versions of MinGW/MSYS; and rename sh.exe > so the "MinGW Makefiles" generator will work. (That rename allows you > to keep bash.exe on your PATH so that all the test suite works for the > "MinGW Makefiles" generator just like it does for the "MSYS Makefiles" > generator.) Or don't rename she.exe and use the "MSYS Makefiles" > generator instead. Well worth experimenting with. > > N.B. you have to download and install the latest automatic installer > for MinGW/MSYS to access the latest MinGW/MSYS. Using the update > command for an older version of that automatic installer does not get > you the latest versions. > > Even if STATIC_OPTS ON turns out to still be necessary with the latest > MinGW and MinGW/MSYS versions of gfortran, I have some questions about the > implementation. For the f95 case and STATIC_OPTS ON we have the > following cmake logic: > > add_library(plplotf95${LIB_TAG} ${plplotf95${LIB_TAG}_LIB_SRCS}) > > if(STATIC_OPTS) > add_library(plplotf95opts${LIB_TAG} STATIC > ${plplotf95opts${LIB_TAG}_LIB_SRCS}) > target_link_libraries(plplotf95${LIB_TAG} plplotf95c${LIB_TAG}) > target_link_libraries(plplotf95opts${LIB_TAG} plplotf95${LIB_TAG} > plplotf95c${LIB_TAG}) > else(STATIC_OPTS) > target_link_libraries(plplotf95${LIB_TAG} plplotf95c${LIB_TAG}) > endif(STATIC_OPTS) > > So it appears for the STATIC_OPTS ON case you are trying to link the > static plplotf95opts${LIB_TAG} library using the shared > plplotf95${LIB_TAG} library as a dependency. > > Such mixtures of shared and static libraries are always tricky to link > correctly. As far as I can tell plplotf95opts${LIB_TAG} only has the > plparseopts7_ symbol undefined which is resolved by > plplotf95c${LIB_TAG}. In other words, I don't believe > plplotf95${LIB_TAG} supplies any symbol required by > plplotf95opts${LIB_TAG}. I would think putting plplotf95c${LIB_TAG} > in the dependent library list for > target_link_libraries(plplotf95opts${LIB_TAG} ....) would be > relatively harmless, but there be some nasty linking side effect that > is causing so I would suggest simplifying the linking logic as follows > for the STATIC_OPTS ON case: > > add_library(plplotf95opts${LIB_TAG} STATIC > ${plplotf95opts${LIB_TAG}_LIB_SRCS}) > target_link_libraries(plplotf95${LIB_TAG} plplotf95c${LIB_TAG}) > target_link_libraries(plplotf95opts${LIB_TAG} plplotf95c${LIB_TAG}) > > This simplified linking means that the examples will need to be linked > to both plplotf95opts${LIB_TAG} and plplotf95${LIB_TAG} for the > STATIC_OPTS ON case, but that is a small price to pay if the result > works. > > There are a number of other possibilities to try such as linking > plplotf95opts${LIB_TAG} separately but as SHARED, or linking it STATIC > but with the -FPIC compile option so that it can be linked > as a dependency of plplotf95${LIB_TAG. But I think your best bets > for solving this are (1) install the latest gfortran version available > for MinGW and try both the "MinGW Makefiles" and "MSYS Makefiles" > generators, or (2) simplify the linking by dropping plplotf95${LIB_TAG} > (as above) as a target_link_libraries dependency of > plplotf95opts${LIB_TAG}. > > If none of those options work, I would be willing to try to test the > combination of the latest wine and latest MinGW/MSYS under Wine to see > if the module issue in that case is now solved so that I can explore > the issue under Wine. But that is a pretty big time committment when > I am tied up with other things so I really hope one of my suggested > options does work for you. I will go and experiment with these. Regards, Arjen 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...> - 2011-11-10 18:31:52
|
On 2011-11-10 08:49+0100 Arjen Markus wrote: > i Alan, > > On 2011-11-09 19:19, Alan W. Irwin wrote: > >> >> Is this the first time you have tested the MinGW version of gfortran >> on Windows for our f95 examples using the "MinGw Makefiles" generator? >> As I recall, I could not get those examples to work on MinGW/Wine for >> the "MSYS Makefiles" generator, but I believe it was a separate issue >> (complaints about the form of the module file). I wrote that off as a >> Wine platform problem and probably didn't get deep enough into the >> testing to run into the problem you describe. >> > > No, the MinGW+gfortran combination (not MSYS) is the one I use most. > It is only very recent that I noticed these issues. Have you ever tested the combination of CMake-2.8.x and MinGW before? I just realized that the -Wl,--allow-multiple-definition option has been automatically set in our cmake/modules/language_support/cmake-2.6/Platform/*.cmake files that override CMake-2.6 language support in the Windows case. If you previously were just using CMake-2.6.x to test this case, then you were always using the -Wl,--allow-multiple-definition option which would explain why you never saw this issue before. However, if it turns out you have successfully tested CMake-2.8.x and MinGW before, then it is important to figure out exactly what has changed between the success you had before and now. For example, if you can show an older version of CMake-2.8.x works but not CMake-2.8.6, that is important information that should be passed on to the CMake developers. You have recently copied 5 Fortran language support files from cmake/modules/language_support/cmake-2.6 to cmake/modules/language_support/cmake-2.8 to propagate the -Wl,--allow-multiple-definition to the CMake-2.8.x case. However, the -Wl,--allow-multiple-definition option is just a brute-force workaround for a more fundamental issue so I hope one of the suggestions I made previously (e.g., installing the latest MinGW version of gfortran) will provide a more fundamental solution to that issue. That would allow you to permanently remove those 5 CMake-2.6.x Fortran language support files in cmake/modules/language_support/cmake-2.8 and therefore give Windows users the full benefits of the improved Fortran language support in CMake-2.8.x. Of course, in any case you should remove those files locally for all your further experiments. Good luck with your further CMake-2.8.6 experiments to find a fundamental way to avoid having to use the -Wl,--allow-multiple-definition workaround. 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); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); 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...> - 2011-11-11 07:57:34
|
Hi Alan, On 2011-11-10 19:31, Alan W. Irwin wrote: > On 2011-11-10 08:49+0100 Arjen Markus wrote: > > > Have you ever tested the combination of CMake-2.8.x and MinGW before? > I just realized that the -Wl,--allow-multiple-definition option has > been automatically set in our > cmake/modules/language_support/cmake-2.6/Platform/*.cmake files that > override CMake-2.6 language support in the Windows case. If you > previously were just using CMake-2.6.x to test this case, then you > were always using the -Wl,--allow-multiple-definition option which > would explain why you never saw this issue before. > No, I had been using CMake-2.8.5 for quite some time. > However, if it turns out you have successfully tested CMake-2.8.x and > MinGW before, then it is important to figure out exactly what has > changed between the success you had before and now. For example, if > you can show an older version of CMake-2.8.x works but not > CMake-2.8.6, that is important information that should be passed on to > the CMake developers. > To get started with the analysis of this problem, my first step was to use the version of gfortran that comes with MinGW 2010. As I recently installed versions 4.6.1 and 4.6.2, I had a hunch that might be the cause. The installation of MinGW 2010 on my PC comes with gfortran 4.5. Running CMake and make with that version of gfortran built all examples smoothly (well, there were some enigmatic warnings about the COMMON blocks, but they were accompanied with a reassuring message that the fix should in general work) and the programs were nicely built. My conclusion right now is that gfortran 4.6.x is causing the trouble. We do not need anything more than the -Wl,--allow-multiple-define option by the way, so if all else fails, we can greatly simplify these extra files. I am going to try and find out why these gfortran routines are incorporated in the DLL and if there is a way to prevent that. Regards, Arjen 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...> - 2011-11-11 19:46:39
|
Hi Arjen: On 2011-11-11 08:57+0100 Arjen Markus wrote: > My conclusion right now [from my tests versus gfortran 4.5.x] is that gfortran 4.6.x is causing the trouble. > We do not need anything more than the -Wl,--allow-multiple-define option > by the way, so if all else fails, we can greatly simplify these extra > files. Thanks for following up so quickly. It's a big relief that you have narrowed this down to a MinGW-gfortran-4.6.x issue. I emphasize MinGW here because my understanding is that MinGW developers have trouble getting their suggested gcc changes (including those to gfortran) upstream to the gcc developers. I don't know who is at fault for that lack of cooperation between MinGW and gcc developers, but the result is the differences between the MinGW and gcc versions of gfortran are larger than strictly necessary. I suggest that you revert all those 2.6.x Fortran support files that you added (so that all our Windows users can benefit from the better Fortran support in native CMake-2.8.6) and instead use the FFLAGS environment variable to set the -Wl,--allow-multiple-define compile option for the MinGW-gfortran-4.6.x case until some MinGW guru can advise you of a better way to deal with this issue. Builds and tests in the Wine environment are something like 5x slower than in the Linux case and completely lock up my machine (due to contention for some critical kernel resource needed by my desktop environment) until the tests are completed. Furthermore, for each new version of wine (there is a new one every two weeks) you have to build or download all PLplot dependencies from scratch. So that explains why I don't test PLplot on the wine platform on a regular basis, but I might get inspired to try that next week. 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); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); 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...> - 2011-11-15 09:48:48
|
Hi Alan, I have removed the platform-dependent files: It turns out that the problem was due to the specific distribution of the gfortran compiler I had chosen, not to the version. (I still need to make a note of that in the release notes). Anyway, I can proceed now with the renovation of the Fortran 95 examples and bindings. Regards, Arjen On 2011-11-11 20:46, Alan W. Irwin wrote: > Hi Arjen: > > On 2011-11-11 08:57+0100 Arjen Markus wrote: > >> My conclusion right now [from my tests versus gfortran 4.5.x] is that >> gfortran 4.6.x is causing the trouble. >> We do not need anything more than the -Wl,--allow-multiple-define option >> by the way, so if all else fails, we can greatly simplify these extra >> files. > > Thanks for following up so quickly. It's a big relief that you have > narrowed this down to a MinGW-gfortran-4.6.x issue. I emphasize MinGW > here because my understanding is that MinGW developers have trouble > getting their suggested gcc changes (including those to gfortran) > upstream to the gcc developers. I don't know who is at fault for that > lack of cooperation between MinGW and gcc developers, but the result > is the differences between the MinGW and gcc versions of gfortran are > larger than strictly necessary. > > I suggest that you revert all those 2.6.x Fortran support files that > you added (so that all our Windows users can benefit from the better > Fortran support in native CMake-2.8.6) and instead use the FFLAGS > environment variable to set the -Wl,--allow-multiple-define compile > option for the MinGW-gfortran-4.6.x case until some MinGW guru can > advise you of a better way to deal with this issue. > > Builds and tests in the Wine environment are something like 5x slower > than in the Linux case and completely lock up my machine (due to > contention for some critical kernel resource needed by my desktop > environment) until the tests are completed. Furthermore, for each new > version of wine (there is a new one every two weeks) you have to build > or download all PLplot dependencies from scratch. So that explains why > I don't test PLplot on the wine platform on a regular basis, but I > might get inspired to try that next week. > > 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); the Time > Ephemerides project (timeephem.sf.net); PLplot scientific plotting > software package (plplot.sf.net); 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 > __________________________ > 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...> - 2011-11-15 17:51:43
|
On 2011-11-15 09:49+0100 Arjen Markus wrote: > Hi Alan, > > I have removed the platform-dependent files: I think you forgot to commit all of that. I finished the job with revision 12029. > It turns out that the problem was due to the specific distribution > of the gfortran compiler I had chosen, not to the version. I am glad you figured out that tricky issue. > > (I still need to make a note of that in the release notes). Yes, please! > > Anyway, I can proceed now with the renovation of the Fortran 95 > examples and bindings. Before you do that, could you just check with your latest MinGW/gfortran whether you can set STATIC_OPTS to OFF in cmake/modules/TestF77CmdLine.cmake for the MinGW case? This whole thread has been about getting the STATIC_OPTS ON workaround for MinGW/gfortran to work, but I am wondering if that STATIC_OPTS ON workaround is really necessary any more? 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); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); 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...> - 2011-11-16 07:18:15
|
On Tue, 15 Nov 2011 09:51:33 -0800 (PST) "Alan W. Irwin" <ir...@be...> wrote: > On 2011-11-15 09:49+0100 Arjen Markus wrote: > >> Hi Alan, >> >> I have removed the platform-dependent files: > > I think you forgot to commit all of that. I finished > the job with revision 12029. Hi Alan, ah, there was something strange going on. I removed the files (I thought) via the SVN client I have, but it insisted on removing the directory as well. > >> It turns out that the problem was due to the specific >>distribution >> of the gfortran compiler I had chosen, not to the >>version. > > I am glad you figured out that tricky issue. > Yes, I needed the help of the gfortran mailing list to put me on track. Luckily they did - it would have cost me a lot of trouble to reproduce it in a small enough example I guess (the first trial, some dummy routines, was unsuccessful). >> >> (I still need to make a note of that in the release >>notes). > > Yes, please! > Will do. >> >> Anyway, I can proceed now with the renovation of the >>Fortran 95 >> examples and bindings. > > Before you do that, could you just check with your >latest > MinGW/gfortran whether you can set STATIC_OPTS to OFF in > cmake/modules/TestF77CmdLine.cmake for the MinGW case? > > This whole thread has been about getting the STATIC_OPTS >ON workaround for > MinGW/gfortran to work, but I am wondering if that >STATIC_OPTS ON > workaround is really necessary any more? > Ah, yes, that is another experiment I can conduct. Will keep you posted. Regards, Arjen 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...> - 2011-11-17 12:28:28
|
Hi Alan, here is a short update on the STATIC_OPTS issue: >> Before you do that, could you just check with your >> latest >> MinGW/gfortran whether you can set STATIC_OPTS to OFF in >> cmake/modules/TestF77CmdLine.cmake for the MinGW case? >> >> This whole thread has been about getting the STATIC_OPTS >> ON workaround for >> MinGW/gfortran to work, but I am wondering if that >> STATIC_OPTS ON >> workaround is really necessary any more? >> > > Ah, yes, that is another experiment I can conduct. > Will keep you posted. > I tested this with gfortran 4.6.2 from TDM (an alternative MinGW distribution, as I could not find - then - the one from the MinGW project itself) and for this version it turned out that everything works fine. But for gfortran 4.5.0 from the MinGW 2010 project I get much less satisfactory results: the example programs cause some nasty error when they finish. Further testing is required, but it does not look as if we can drop that option yet. Regards, Arjen 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...> - 2011-11-17 20:17:16
|
Hi Arjen: On 2011-11-17 13:28+0100 Arjen Markus wrote: [Alan wrote:] >>> This whole thread has been about getting the STATIC_OPTS >>> ON workaround for >>> MinGW/gfortran to work, but I am wondering if that >>> STATIC_OPTS ON >>> workaround is really necessary any more? > > I tested this with gfortran 4.6.2 from TDM (an alternative > MinGW distribution, as I could not find - then - the one > from the MinGW project itself) and for this version it > turned out that everything works fine. > > But for gfortran 4.5.0 from the MinGW 2010 project I couldn't find that on the web. Is that a separate project or just your designation for the MinGW project itself? > I get > much less satisfactory results: the example programs > cause some nasty error when they finish. Further testing > is required, but it does not look as if we can drop that > option yet. Thanks for those additional tests. I am very glad to hear that workaround is not necessary for at least one distribution of a (very) recent MinGW version. I agree we should keep the workaround for now, but let us revisit this again in the future (say roughly a year from now). I have entered a bug report (https://sourceforge.net/tracker/?func=detail&aid=3439533&group_id=2915&atid=102915) to that effect to remind us. Also, the availability of these additional MinGW distributions you have discovered leads to two fairly obvious additional points: I. This interest in additional distributions of MinGW (with or without MSYS) confirms that is the most important of our Windows' platforms by far (as also confirmed by the large number of downloads of MinGW from the SF site). II. The focus of our testing of that important platform should be the "upstream" MinGW distribution you get using the latest version (currently 20110802) of the automatic MinGW (and MSYS if you like) installer you can download from http://sourceforge.net/projects/mingw/files/Installer/mingw-get-inst. That is the preferred MinGW installer (as confirmed by the ~30 thousand downloads of that automatic installer alone), and presumably that distribution is the basis of all other MinGW distributions. So if something works for that automatically installed upstream distribution of MinGW (with or without MSYS), that tests what a lot of people are already using for their MinGW distribution. It is also an approximate test of the other distributions of MinGW since fixes in that upstream distribution should eventually propagate to the rest, and (with luck) whatever the add-ons provided by the rest won't interfere with the PLplot results for the upstream distribution. 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); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); 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 __________________________ |