From: Michael M. T. <mt...@ma...> - 2007-08-28 11:44:52
|
> Date: Mon, 27 Aug 2007 09:19:30 -0700 (PDT) > > Hi Michael: > > I am answering you on list because I think others may be interested in the > reply. > > We have both a legacy f77 binding and a more modern f95 binding. But our > build system assumes just one fortran compiler specified by the user. Our > build system tests that designated compiler against some simple f95 source, > and if it cannot handle it, then it disables the f95 binding which is what > happened to you for your default g77 compiler. (As an aside, > we don't test whether the designated compiler can handle our f77 binding > since our experience is all fortran compilers can handle it.) > > Reading between the lines, I think you want full control over your fortran > compiler rather than the default g77 one picked by cmake. To give you that > control, use the FC environment variable (where you can specify the fortran > command and associated options) before cmake is invoked in an empty > directory for the first time (assuming you are doing an out-of-source > build). e.g., > > export FC='f95 -O2' > cmake -D options <path to PLplot source> > make > make install > > This is documented at http://www.miscdebris.net/plplot_wiki > (look for "1.2.1.2 (Optional) set environment variables to specify the > compilers and compiler flags"), but I can see why you missed it since there > is a lot of information to absorb from our wiki when encountering cmake > for the first time. > > If you run into any trouble with the above scenario for deciding your > fortran compiler, please post to the list the actual export and cmake > commands you used and the complete output from the cmake command (which > will > help us to diagnose the problem). > > Alan Dear Alan: I also reply to your message on this list, in case other people face similar questions. I had been trying setting the F95 command before, in two ways, exporting from the command line (as you suggested in the last message) and from within the ccmake menu. In both cases cmake is reconfiguring and setting finally ENABLE_f95 to OFF. I tried to force ENABLE_f95 ON desperately, but ccmake/cmake doesn't seem to like it! Finally, I took the 5.7.3 with configure mode with --enable-f95 and the F95 compiler was found automatically. The compilation went smoothly, except for two minor changes. The option --tag=F77 had to be added to the f95 Makefile in the lines where libtool is called. Further, the lines with the equivalence command in sfstubs.h had to be commented out (this probably depends on the F95 compiler used). All example programs with F95 run. The character charts for the symbols don't turn out right, however. But perhaps that's a problem related to my locales as the error message is 'UTF-8 string is malformed'. Strangely, the error doesn't show up in the F77 examples. Perhaps, it would be good to keep the configure compile option as fallback option in the future releases of PLplot. An advantage seems to be that one can specify separately the F77 and F95 flags, e.g. F77 FFLAGS: g77 -g -O2 FC FCFLAGS: f95 -g -O2 . Again many thanks for your help. Keep up the good work! Best, Michael -- |
From: Michael M. T. <mt...@ma...> - 2007-08-28 13:30:03
Attachments:
x01f.jpg
|
Dear Alan: It looks like the missing symbol fonts in the F95 binding is related to the equivalence commands in the sfstubs.h file: integer maxlen parameter (maxlen = 320) character*(maxlen) string1, string2, string3 character*(maxlen) string4, string5, string6 character*(maxlen) string7, string8, string9 integer s1(80), s2(80), s3(80), s4(80), s5(80), s6(80), s7(80), s8(80), s9(80) equivalence ( s1, string1 ), ( s2, string2 ) equivalence ( s3, string3 ), ( s4, string4 ) equivalence ( s5, string5 ), ( s6, string6 ) equivalence ( s7, string7 ), ( s8, string8 ) equivalence ( s9, string9 ) which upon compilation gives the error Warning: sfstubs.h, line 28: EQUIVALENCE of default char with default numeric and exits. Probably my compiler does not comply with the extension to the ANSI 77 Standard in which character and non-character data items can share the same storage space. I forced an uninterrupted compilation (with plenty of warnings, though) using an option for backwards compatibility with F77, but still the symbols don't show up correctly (see attached JPEG output of x01f.f90). Would there be a more direct way (perhaps derived types) modifying the equivalence code and getting rid of this problem? Best, Michael -- |
From: Arjen M. <arj...@wl...> - 2007-08-28 13:39:37
|
Michael M. Tung wrote: >Dear Alan: > >It looks like the missing symbol fonts in the F95 binding is related to the >equivalence commands in the sfstubs.h file: > > integer maxlen > parameter (maxlen = 320) > character*(maxlen) string1, string2, string3 > character*(maxlen) string4, string5, string6 > character*(maxlen) string7, string8, string9 > integer s1(80), s2(80), s3(80), s4(80), s5(80), s6(80), s7(80), s8(80), s9(80) > equivalence ( s1, string1 ), ( s2, string2 ) > equivalence ( s3, string3 ), ( s4, string4 ) > equivalence ( s5, string5 ), ( s6, string6 ) > equivalence ( s7, string7 ), ( s8, string8 ) > equivalence ( s9, string9 ) > >which upon compilation gives the error > > Warning: sfstubs.h, line 28: EQUIVALENCE of default char with default numeric > >and exits. > >Probably my compiler does not comply with the extension to the ANSI 77 Standard >in which character and non-character data items can share the same storage space. >I forced an uninterrupted compilation (with plenty of warnings, though) using >an option for backwards compatibility with F77, but still the symbols don't >show up correctly (see attached JPEG output of x01f.f90). > >Would there be a more direct way (perhaps derived types) modifying the equivalence >code and getting rid of this problem? > > We reused the method from the FORTRAN 77 interface, but if this is really causing this trouble (well, the error messages about the equivalencing of character and numeric data are troublesome enough), then we need to rethink this. It should not be that difficult ... Regards, Arjen |
From: Michael M. T. <mt...@ma...> - 2007-08-28 16:11:56
|
Arjen Markus [arj...@wl...] wrote: > Michael M. Tung wrote: > >> Dear Alan: >> >> It looks like the missing symbol fonts in the F95 binding is related to >> the >> equivalence commands in the sfstubs.h file: >> >> integer maxlen >> parameter (maxlen = 320) >> character*(maxlen) string1, string2, string3 >> character*(maxlen) string4, string5, string6 >> character*(maxlen) string7, string8, string9 >> integer s1(80), s2(80), s3(80), s4(80), s5(80), s6(80), s7(80), >> s8(80), s9(80) >> equivalence ( s1, string1 ), ( s2, string2 ) >> equivalence ( s3, string3 ), ( s4, string4 ) >> equivalence ( s5, string5 ), ( s6, string6 ) >> equivalence ( s7, string7 ), ( s8, string8 ) >> equivalence ( s9, string9 ) >> >> which upon compilation gives the error >> >> Warning: sfstubs.h, line 28: EQUIVALENCE of default char with default >> numeric >> >> and exits. >> >> Probably my compiler does not comply with the extension to the ANSI 77 >> Standard >> in which character and non-character data items can share the same storage >> space. >> I forced an uninterrupted compilation (with plenty of warnings, though) >> using >> an option for backwards compatibility with F77, but still the symbols >> don't >> show up correctly (see attached JPEG output of x01f.f90). >> >> Would there be a more direct way (perhaps derived types) modifying the >> equivalence >> code and getting rid of this problem? >> > We reused the method from the FORTRAN 77 interface, but if this is really > causing > this trouble (well, the error messages about the equivalencing of character > and numeric > data are troublesome enough), then we need to rethink this. It should not > be that difficult ... > > Regards, > > Arjen > Dear Arjen, thanks, if you have any solution, let me know so that I can try it out with my F95 compiler. Best, Michael -- |
From: Alan W. I. <ir...@be...> - 2007-08-28 16:18:03
|
On 2007-08-28 13:44+0200 Michael M. Tung wrote: >> Date: Mon, 27 Aug 2007 09:19:30 -0700 (PDT) >> [...] I think you want full control over your fortran >> compiler rather than the default g77 one picked by cmake. To give you that >> control, use the FC environment variable (where you can specify the fortran >> command and associated options) before cmake is invoked in an empty >> directory for the first time (assuming you are doing an out-of-source >> build). e.g., >> >> export FC='f95 -O2' >> cmake -D options <path to PLplot source> >> make >> make install >> >> This is documented at http://www.miscdebris.net/plplot_wiki >> (look for "1.2.1.2 (Optional) set environment variables to specify the >> compilers and compiler flags"), but I can see why you missed it since there >> is a lot of information to absorb from our wiki when encountering cmake >> for the first time. >> >> If you run into any trouble with the above scenario for deciding your >> fortran compiler, please post to the list the actual export and cmake >> commands you used and the complete output from the cmake command (which >> will >> help us to diagnose the problem). >> >> Alan > > Dear Alan: > > I also reply to your message on this list, in case > other people face similar questions. > > I had been trying setting the F95 command before, in > two ways, exporting from the command line (as you > suggested in the last message) and from within the > ccmake menu. In both cases cmake is reconfiguring > and setting finally ENABLE_f95 to OFF. I tried to > force ENABLE_f95 ON desperately, but ccmake/cmake > doesn't seem to like it! Hi Michael: It sounds like you have a stale cache problem from attempting to re-run after the first error is encountered. ccmake also has caching issues that obfuscate problems. Therefore, please start again in an empty build tree following the directions above (export; cmake [not ccmake]; make; etc.). If the problem persists, we can only help you further if you give us complete specifics (i.e., exact export and cmake commands, full cmake output from the time you run cmake in an empty build tree, full make output). My personal experience is setting the FC environment variable "just works" for systems which have either g77 or gfortran. Other developers here have reported good success with a number of additional fortran compilers. Thus, whatever the issue you are having, I feel confident we can solve it if you give us the requested specifics. 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: Michael M. T. <mt...@ma...> - 2007-08-31 09:12:25
Attachments:
out
|
Alan W. Irwin [ir...@be...] wrote: > Hi Michael: > > It sounds like you have a stale cache problem from attempting to re-run > after the first error is encountered. ccmake also has caching issues that > obfuscate problems. Therefore, please start again in an empty build tree > following the directions above (export; cmake [not ccmake]; make; etc.). > > If the problem persists, we can only help you further if you give us > complete specifics (i.e., exact export and cmake commands, full cmake > output > from the time you run cmake in an empty build tree, full make output). > > My personal experience is setting the FC environment variable "just works" > for > systems which have either g77 or gfortran. Other developers here have > reported good success with a number of additional fortran compilers. Thus, > whatever the issue you are having, I feel confident we can solve it if you > give us the requested specifics. > > Alan > __________________________ > Alan W. Irwin > Dear Alan: Finally cmake recognizes both flags, ENABLE_f77:BOOL=ON and ENABLE_f95:BOOL=ON. I am not sure what the problem was---perhaps ccmake was in some way interfering with plain cmake. Compilation, unfortunately, still stops at about 27%, because of the EQUIVALENCE conflict in F95 (due to incompatibilities with F77). I attach the error messages. Hopefully, somebody has a quick fix for this problem or some ideas on how to adapt this code to F95. Best regards, Michael -- |
From: Arjen M. <arj...@wl...> - 2007-08-31 09:29:05
|
Michael M. Tung wrote: > >Finally cmake recognizes both flags, ENABLE_f77:BOOL=ON >and ENABLE_f95:BOOL=ON. I am not sure what the problem >was---perhaps ccmake was in some way interfering with >plain cmake. > >Compilation, unfortunately, still stops at about 27%, >because of the EQUIVALENCE conflict in F95 (due to >incompatibilities with F77). I attach the error messages. >Hopefully, somebody has a quick fix for this problem or >some ideas on how to adapt this code to F95. > > > Hi Michael, I will look into the matter of the EQUIVALENCE statements (real life, as they say, may get in the way of a quick and clean solution ...) But in the meantime, could you try and work around this by using, say, g77 for only the FORTRAN 77 bindings? Just to make sure that that would be working for you? Regards, Arjen |
From: Arjen M. <arj...@wl...> - 2007-08-31 10:55:19
|
Michael M. Tung wrote: >Arjen Markus [arj...@wl...] wrote: > > >>Hi Michael, >> >>I will look into the matter of the EQUIVALENCE statements >>(real life, as they say, may get in the way of a quick and >>clean solution ...) >>But in the meantime, could you try and work around this by >>using, say, g77 for only the FORTRAN 77 bindings? >>Just to make sure that that would be working for you? >> >>Regards, >> >>Arjen >> >> > >Dear Arjen, > >the FORTRAN 77 bindings compile and work without any >problems. Thanks for looking at the problem. No hurry, >and a quick and dirty solution is also helpful. :-) > > > The quick and dirty solution (probably useful for the final one too) is to: - Remove the equivalence statements in sfstubs.h - Use the transfer() function like this: The current implementation reads: subroutine plsetopt(opt, optarg) implicit none character*(*) opt, optarg include 'sfstubs.h' call plstrf2c(opt, string1, maxlen) call plstrf2c(optarg, string2, maxlen) call plsetopt7(s1, s2) end subroutine Replace the call to plsetopt7 by: s1 = transfer(string1,s1) s2 = transfer(string2.s2) call plsetopt7(s1,s2) And likewise for all other uses of s1, ...., s9 (The effect is that the contents of the strings are copied byte-for-byte to the integer arrays s1, etc. Slightly more work than the EQUIVALENCE case, but quite standard) Regards, Arjen |
From: Michael M. T. <mt...@ma...> - 2007-09-28 15:18:43
|
Dear Arjen: I just got around to check the F95 binding of the latest SVN release. Everything is fine! The characters now display correctly for the F95 examples. In the file binding/f95/Makefile I had to add the '--tag=F77' option in the two lines so that they look: ... $(LIBTOOL) --tag=F77 --mode=compile ... ... $(LIBTOOL) --tag=F77 --mode=link ... I have been testing with a NAGWare Fortran 95 compiler and will also try out the Absoft F95 compiler. Many thanks again. Best, Mike Arjen Markus [arj...@wl...] wrote: > Hello, > > in view of the recent report on problems with EQUIVALENCE'ing > integers and character strings in the Fortran 95 bindings, I have > changed the implementation. Instead of an EQUIVALENCE > statement the transfer of character data from Fortran routines > to C functions now goes via the TRANSFER() function. > > As this is completely standard in Fortran 95, the bindings should now > be acceptable for all Fortran 95 compilers. > > I have tested this new implementation with the various examples > and they all work fine. It is possible, however, that one or two > functions are not exercised that way or that I have overlooked > something. So, please report any strange results. > > To use this new implementation, update the sources from SVN. > > Regards, > > Arjen -- |
From: Arjen M. <arj...@wl...> - 2007-10-01 06:19:00
|
Michael M. Tung wrote: >Dear Arjen: > >I just got around to check the F95 binding of the latest SVN release. > >Everything is fine! The characters now display correctly for the F95 >examples. In the file binding/f95/Makefile I had to add the '--tag=F77' >option in the two lines so that they look: > >... $(LIBTOOL) --tag=F77 --mode=compile ... >... $(LIBTOOL) --tag=F77 --mode=link ... > >I have been testing with a NAGWare Fortran 95 compiler and will also try >out the Absoft F95 compiler. > > > Hello Michael, great! The only thing I do not quite understand is the --tag, is that a compiler-specific addition you need? (Never needed it under Cygwin or Mingw) Regards, Arjen |
From: Arjen M. <arj...@wl...> - 2007-09-05 06:34:44
|
Hello, in view of the recent report on problems with EQUIVALENCE'ing integers and character strings in the Fortran 95 bindings, I have changed the implementation. Instead of an EQUIVALENCE statement the transfer of character data from Fortran routines to C functions now goes via the TRANSFER() function. As this is completely standard in Fortran 95, the bindings should now be acceptable for all Fortran 95 compilers. I have tested this new implementation with the various examples and they all work fine. It is possible, however, that one or two functions are not exercised that way or that I have overlooked something. So, please report any strange results. To use this new implementation, update the sources from SVN. Regards, Arjen |