Hi Arjen,
Yes, this worked! I was now able to compile and install plplot for
pgf-13.6. Thank you very much for your help!
--
Irena
On Wed, Aug 27, 2014 at 10:02 AM, Arjen Markus <arjen.mar...@deltares.nl>
wrote:
> Hi Irena,
>
>
>
> Odd, the only thing I can think of is that the compiler does not like this
> combination of a module procedure and an explicit interface block. Could
> you try with:
>
> interface plsvect
>
> module procedure plsvect1
>
> end interface
>
> interface plsvect
>
> subroutine plsvect2
>
> end subroutine plsvect2
>
> end interface
>
> (Change it directly in the file sfstubs95.f90)
>
>
>
> You can specify multiple interfaces with the same name as long as the
> individual routines can be distinguished
>
> If this does not work either, it is time for me to consult the
> comp.lang.fortran group.
>
>
>
> Regards,
>
>
>
> Arjen
>
>
>
>
>
>
> *From:* Irena Johnson [mailto:ijohn...@pppl.gov]
> *Sent:* Wednesday, August 27, 2014 3:55 PM
> *To:* Arjen Markus
> *Cc:* Alan W. Irwin; plplot-general@lists.sourceforge.net
>
> *Subject:* Re: [Plplot-general] continuation lines in
> bindings/tcl/plplot_parameters.h
>
>
>
> Hi Arjen,
>
>
>
> I am getting the same error:
>
>
>
> $ pgf95 -g -Minfo=all -v ../dummy.f90
>
>
>
> /usr/pppl/pgi/13.6/linux86-64/13.6/bin/pgf901 ../dummy.f90 -debug -x 120
> 0x200 -opt 0 -inform inform -nohpf -nostatic -tp k8e -x 19 0x400000 -quad
> -x 59 4 -x 59 4 -x 15 2 -x 49 0x400004 -x 51 0x20 -x 57 0x4c -x 58 0x10000
> -x 124 0x1000 -x 57 0xfb0000 -x 58 0x78031040 -x 48 4608 -x 49 0x100 -x 120
> 0x200 -stdinc
> /usr/pppl/pgi/13.6/linux86-64/13.6/include:/usr/local/include:/usr/lib/gcc/x86_64-redhat-linux/4.1.2/include:/usr/lib/gcc/x86_64-redhat-linux/4.1.2/include:/usr/include
> -def unix -def __unix -def __unix__ -def linux -def __linux -def __linux__
> -def __NO_MATH_INLINES -def __x86_64 -def __x86_64__ -def
> __LONG_MAX__=9223372036854775807L -def '__SIZE_TYPE__=unsigned long int'
> -def '__PTRDIFF_TYPE__=long int' -def __THROW= -def __extension__= -def
> __amd_64__amd64__ -def __k8 -def __k8__ -def __SSE__ -def __MMX__ -def
> __SSE2__ -def __SSE3__ -freeform -vect 48 -y 54 1 -x 70 0x40000000 -x 49
> 0x1000 -modexport /tmp/pgf95QGsb_y8X0eLt.cmod -modindex
> /tmp/pgf956GsbUGFEBSoq.cmdx -output /tmp/pgf95AGsboF4nTv5R.ilm
>
> *PGF90-S-0070-Incorrect sequence of statements* (../dummy.f90: 7)
>
> 0 inform, 0 warnings, 1 severes, 0 fatal for dummy
>
> 0 inform, 0 warnings, 0 severes, 0 fatal for plsvect1
>
> PGF90/x86-64 Linux 13.6-0: compilation completed with severe errors
>
> pgf95-Fatal-f901 completed with exit code 1
>
>
>
>
>
>
>
> From http://www.pgroup.com/doc/pghpf_ug/hpfug12.htm,
>
>
>
> *S 70 "Incorrect sequence of statements $"*
>
> The statement order is incorrect. For instance, an IMPLICIT NONE statement
> must precede a specification statement which in turn must precede an
> executable statement.
>
>
>
> Thanks,
>
> --Irena
>
>
>
> On Wed, Aug 27, 2014 at 9:21 AM, Arjen Markus <arjen.mar...@deltares.nl>
> wrote:
>
> Hi Irena,
>
>
>
> That is rather odd, the code is correct as far as I can tell. Could you
> try to compile this code:
>
>
>
> module dummy
>
> interface plsvect
>
> module procedure plsvect1
>
> subroutine plsvect2
>
> end subroutine plsvect2
>
> end interface
>
> contains
>
> subroutine plsvect1( x )
>
> real :: x
>
> end subroutine plsvect1
>
> end module dummy
>
>
>
>
>
> This should be perfectly acceptable code. If not, the PG compiler is doing
> something odd. Can you use a flag that will tell us more about what is
> wrong according to the compiler?
>
>
>
> Regards,
>
>
>
> Arjen
>
>
>
>
> *From:* Irena Johnson [mailto:ijohn...@pppl.gov]
> *Sent:* Wednesday, August 27, 2014 2:43 PM
> *To:* Alan W. Irwin
> *Cc:* plplot-general@lists.sourceforge.net
> *Subject:* Re: [Plplot-general] continuation lines in
> bindings/tcl/plplot_parameters.h
>
>
>
> Hi Alan, plplot_parameters.h
>
>
>
> Thank you for your help with this issue: I got the latest version of
> plplot from git and your modification to plplot_parameters.h has worked!!
>
>
>
> Unfortunately, the compiler now fails with "PGF90-S-0070-Incorrect
> sequence of statements"
>
>
>
>
>
> [ 24%] Built target plplotf95c
>
> Scanning dependencies of target plplotf95
>
> [ 25%] Building Fortran object
> bindings/f95/CMakeFiles/plplotf95.dir/strutil.f90.o
>
> [ 25%] Building Fortran object
> bindings/f95/CMakeFiles/plplotf95.dir/sfstubsf95.f90.o
>
> PGF90-S-0070-Incorrect sequence of statements
> (/pfs/tmp/ijohnson/plplot.git/bindings/f95/sfstubsf95.f90: 905)
>
> 0 inform, 0 warnings, 1 severes, 0 fatal for plplot
>
> make[3]: *** [bindings/f95/CMakeFiles/plplotf95.dir/sfstubsf95.f90.o]
> Error 2
>
> make[2]: ***
> [bindings/f95/CMakeFiles/plplotf95.dir/sfstubsf95.f90.o.provides] Error 2
>
> make[1]: *** [bindings/f95/CMakeFiles/plplotf95.dir/all] Error 2
>
> make: *** [all] Error 2
>
>
>
> Thank you,
>
> --Irena
>
>
>
> On Tue, Aug 26, 2014 at 7:00 PM, Alan W. Irwin <ir...@beluga.phys.uvic.ca>
> wrote:
>
> On 2014-08-26 13:21-0700 Alan W. Irwin wrote:
>
> Getting back to the principal issue, it appears to me that gcc is
> accepting all those "\n\" continuation lines in
> bindings/tcl/plplot_parameters.h, but your Portland Group compiler is
> not. We will look further at this.
>
>
>
> Hi Irena:
>
> I have now changed the style of plplot_parameters.h to replace one huge
> string
> literal by a large number of small string literals that the compiler
> should automatically concatenate together.
>
> I prefer this new style on general principles, and gcc compiles this
> style just as well as the old style. It's possible your Portland Group
> compiler will still choke on this style as it attempts to concatenate
> those string literals together. But on the other hand, it might work.
>
> To test that possibility, please try the latest version of our
> source code using
>
> git clone git://git.code.sf.net/p/plplot/plplot plplot.git
>
> Then try your normal build (with -DENABLE_tcl=ON or else by removing
> -DENABLE_tcl=OFF from the cmake command line since ENABLE_tcl is ON by
> default) referring to this version of the source tree rather than
> 5.10.0 and starting from an empty build tree. If your compiler is
> able to compile bindings/tcl/tclAPI.c without issues, then the change in
> style
> should be judged a success.
>
> Furthermore, I hope your set of Portland Group compilers is able to
> finish the rest of a default build of PLplot without issues, but if
> there are such issues we will try to deal with them since we prefer to
> have PLplot builds be successful on all compilers and not just gcc.
>
> By the way, I think the above is the first reference to our new
> official git repository on this list (although there has been a large
> amount of traffic about this huge change in PLplot development on the
> plplot-devel list). The short story is our svn repository at SF is
> now frozen in read-only mode and as of a few days ago we switched to
> using git for PLplot development with the above being our official git
> repo. I am pretty much a git newbie myself, but my use of it for the
> last several days shows it is an extremely popular version control
> system for good reasons. Therefore, I think there is an excellent
> chance this change from subversion to git will not only help our
> current set of developers but also attract new developers to the
> project.
>
>
>
> 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.
>
>
>
>
> 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.
>
------------------------------------------------------------------------------
Slashdot TV.
Video for Nerds. Stuff that matters.
http://tv.slashdot.org/
_______________________________________________
Plplot-general mailing list
Plplot-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-general
