From: Irena J. <ijo...@pp...> - 2014-08-26 18:35:59
|
Hello, I am trying to compile plplot-5.10.0 for PGF-13.6 and am getting the following error: $ make 2>&1 |tee log.make [ 0%] Built target deltaT-gen [ 1%] Built target deltaT.h_built [ 2%] Built target tai-utc-gen [ 2%] Built target tai-utc.h_built [ 2%] Built target qsastime [ 2%] Built target plhershey-unicode-gen [ 2%] Built target plhershey-unicode.h_built [ 3%] Building C object src/CMakeFiles/plplotd.dir/__/bindings/tcl/tclAPI.c.o PGC-F-0223-String too long (/pfs/tmp/ijohnson/plplot-5.10.0/bindings/tcl/plplot_parameters.h: 15) PGC/x86-64 Linux 13.6-0: compilation aborted make[2]: *** [src/CMakeFiles/plplotd.dir/__/bindings/tcl/tclAPI.c.o] Error 2 make[1]: *** [src/CMakeFiles/plplotd.dir/all] Error 2 make: *** [all] Error 2 Could you please advise? Thank you! -- Irena |
From: Arjen M. <Arj...@de...> - 2014-08-27 14:02:50
|
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:ijo...@pp...] Sent: Wednesday, August 27, 2014 3:55 PM To: Arjen Markus Cc: Alan W. Irwin; plp...@li... 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 <Arj...@de...<mailto:Arj...@de...>> 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:ijo...@pp...<mailto:ijo...@pp...>] Sent: Wednesday, August 27, 2014 2:43 PM To: Alan W. Irwin Cc: plp...@li...<mailto:plp...@li...> 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...@be...<mailto:ir...@be...>> 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<http://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<http://astrowww.phys.uvic.ca>). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net<http://freeeos.sf.net>); the Time Ephemerides project (timeephem.sf.net<http://timeephem.sf.net>); PLplot scientific plotting software package (plplot.sf.net<http://plplot.sf.net>); the libLASi project (unifont.org/lasi<http://unifont.org/lasi>); the Loads of Linux Links project (loll.sf.net<http://loll.sf.net>); and the Linux Brochure Project (lbproject.sf.net<http://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. |
From: Davide C. <dc...@ar...> - 2014-08-27 14:30:41
|
Hi Irena and Arjen, just to add some information: I have Fortran PGI compiler available, version 13.10 [dcesari@malina ~]$ pgfortran --version pgfortran 13.10-0 64-bit target on x86-64 Linux -tp p7 The Portland Group - PGI Compilers and Tools Copyright (c) 2013, NVIDIA CORPORATION. All rights reserved. and it seems that it is capable to compile successfully both Arjen code excerpt as well as the complete sfstubsf95.f90 extracted from git together with the dependencies, can we compare the versions? I almost stopped using PGI because it tends to fail on many correct pieces of code even sticking to strict f90 standard, however some bugs are fixed from time to time. Davide On 27/08/2014 16:02, Arjen Markus 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:ijo...@pp...] > *Sent:* Wednesday, August 27, 2014 3:55 PM > *To:* Arjen Markus > *Cc:* Alan W. Irwin; plp...@li... > *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 <Arj...@de... > <mailto:Arj...@de...>> 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:ijo...@pp... <mailto:ijo...@pp...>] > *Sent:* Wednesday, August 27, 2014 2:43 PM > *To:* Alan W. Irwin > *Cc:* plp...@li... > <mailto:plp...@li...> > *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...@be... <mailto:ir...@be...>> 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 > <http://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 > <http://astrowww.phys.uvic.ca>). > > Programming affiliations with the FreeEOS equation-of-state > implementation for stellar interiors (freeeos.sf.net > <http://freeeos.sf.net>); the Time > Ephemerides project (timeephem.sf.net <http://timeephem.sf.net>); PLplot > scientific plotting > software package (plplot.sf.net <http://plplot.sf.net>); the libLASi project > (unifont.org/lasi <http://unifont.org/lasi>); the Loads of Linux Links > project (loll.sf.net <http://loll.sf.net>); > and the Linux Brochure Project (lbproject.sf.net <http://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 > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-general > -- ============================= Davide Cesari ============================ Dott**(0.5) Davide Cesari ARPA-Emilia Romagna, Servizio IdroMeteoClima NWP modelling - Modellistica numerica previsionale Tel. +39 051525926 ======================================================================== |
From: Irena J. <ijo...@pp...> - 2014-08-27 14:45:43
|
Hi Davide, OK, thanks for the info. It might be good to try the newer version of pgi-13, but we have a lot of customized software here for our scientists and sometimes they require a specific version of a compiler. $ pgfortran --version pgfortran 13.6-0 64-bit target on x86-64 Linux -tp k8e Copyright 1989-2000, The Portland Group, Inc. All Rights Reserved. Copyright 2000-2013, STMicroelectronics, Inc. All Rights Reserved. Thanks, --Irena On Wed, Aug 27, 2014 at 10:15 AM, Davide Cesari <dc...@ar...> wrote: > Hi Irena and Arjen, just to add some information: I have Fortran PGI > compiler available, version 13.10 > > [dcesari@malina ~]$ pgfortran --version > pgfortran 13.10-0 64-bit target on x86-64 Linux -tp p7 > The Portland Group - PGI Compilers and Tools > Copyright (c) 2013, NVIDIA CORPORATION. All rights reserved. > > and it seems that it is capable to compile successfully both Arjen code > excerpt as well as the complete sfstubsf95.f90 extracted from git > together with the dependencies, can we compare the versions? I almost > stopped using PGI because it tends to fail on many correct pieces of > code even sticking to strict f90 standard, however some bugs are fixed > from time to time. > Davide > > > > On 27/08/2014 16:02, Arjen Markus 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:ijo...@pp...] > > *Sent:* Wednesday, August 27, 2014 3:55 PM > > *To:* Arjen Markus > > *Cc:* Alan W. Irwin; plp...@li... > > *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 <Arj...@de... > > <mailto:Arj...@de...>> 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:ijo...@pp... <mailto:ijo...@pp... > >] > > *Sent:* Wednesday, August 27, 2014 2:43 PM > > *To:* Alan W. Irwin > > *Cc:* plp...@li... > > <mailto:plp...@li...> > > *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...@be... <mailto:ir...@be...>> 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 > > <http://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 > > <http://astrowww.phys.uvic.ca>). > > > > Programming affiliations with the FreeEOS equation-of-state > > implementation for stellar interiors (freeeos.sf.net > > <http://freeeos.sf.net>); the Time > > Ephemerides project (timeephem.sf.net <http://timeephem.sf.net>); PLplot > > scientific plotting > > software package (plplot.sf.net <http://plplot.sf.net>); the libLASi > project > > (unifont.org/lasi <http://unifont.org/lasi>); the Loads of Linux Links > > project (loll.sf.net <http://loll.sf.net>); > > and the Linux Brochure Project (lbproject.sf.net < > http://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 > > Plp...@li... > > https://lists.sourceforge.net/lists/listinfo/plplot-general > > > > > -- > ============================= Davide Cesari ============================ > Dott**(0.5) Davide Cesari > ARPA-Emilia Romagna, Servizio IdroMeteoClima > NWP modelling - Modellistica numerica previsionale > Tel. +39 051525926 > ======================================================================== > > > ------------------------------------------------------------------------------ > Slashdot TV. > Video for Nerds. Stuff that matters. > http://tv.slashdot.org/ > _______________________________________________ > Plplot-general mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-general > -- Irena |
From: Arjen M. <Arj...@de...> - 2014-08-28 08:15:46
|
Hi Davide, Thanks for that information. It confirms my suspicions about the nature of the error message. Luckily the workaround is simple enough. Regards, Arjen > -----Original Message----- > From: Davide Cesari [mailto:dc...@ar...] > Sent: Wednesday, August 27, 2014 4:15 PM > To: plp...@li... > Subject: Re: [Plplot-general] continuation lines in bindings/tcl/plplot_parameters.h > > Hi Irena and Arjen, just to add some information: I have Fortran PGI compiler > available, version 13.10 > > [dcesari@malina ~]$ pgfortran --version > pgfortran 13.10-0 64-bit target on x86-64 Linux -tp p7 The Portland Group - PGI > Compilers and Tools Copyright (c) 2013, NVIDIA CORPORATION. All rights > reserved. > > and it seems that it is capable to compile successfully both Arjen code excerpt as > well as the complete sfstubsf95.f90 extracted from git together with the > dependencies, can we compare the versions? I almost stopped using PGI because it > tends to fail on many correct pieces of code even sticking to strict f90 standard, > however some bugs are fixed from time to time. > Davide > > > > On 27/08/2014 16:02, Arjen Markus 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:ijo...@pp...] > > *Sent:* Wednesday, August 27, 2014 3:55 PM > > *To:* Arjen Markus > > *Cc:* Alan W. Irwin; plp...@li... > > *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-linu > > x/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 > > <Arj...@de... <mailto:Arj...@de...>> 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:ijo...@pp... > > <mailto:ijo...@pp...>] > > *Sent:* Wednesday, August 27, 2014 2:43 PM > > *To:* Alan W. Irwin > > *Cc:* plp...@li... > > <mailto:plp...@li...> > > *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...@be... <mailto:ir...@be...>> 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 > > <http://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 > > <http://astrowww.phys.uvic.ca>). > > > > Programming affiliations with the FreeEOS equation-of-state > > implementation for stellar interiors (freeeos.sf.net > > <http://freeeos.sf.net>); the Time Ephemerides project > > (timeephem.sf.net <http://timeephem.sf.net>); PLplot scientific > > plotting software package (plplot.sf.net <http://plplot.sf.net>); the > > libLASi project (unifont.org/lasi <http://unifont.org/lasi>); the > > Loads of Linux Links project (loll.sf.net <http://loll.sf.net>); and > > the Linux Brochure Project (lbproject.sf.net <http://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 > > Plp...@li... > > https://lists.sourceforge.net/lists/listinfo/plplot-general > > > > > -- > ============================= Davide Cesari > ============================ > Dott**(0.5) Davide Cesari > ARPA-Emilia Romagna, Servizio IdroMeteoClima NWP modelling - Modellistica > numerica previsionale Tel. +39 051525926 > ============================================================= > =========== > > ------------------------------------------------------------------------------ > Slashdot TV. > Video for Nerds. Stuff that matters. > http://tv.slashdot.org/ > _______________________________________________ > Plplot-general mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-general 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: Irena J. <ijo...@pp...> - 2014-08-27 14:41:46
|
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 <Arj...@de...> 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:ijo...@pp...] > *Sent:* Wednesday, August 27, 2014 3:55 PM > *To:* Arjen Markus > *Cc:* Alan W. Irwin; plp...@li... > > *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 <Arj...@de...> > 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:ijo...@pp...] > *Sent:* Wednesday, August 27, 2014 2:43 PM > *To:* Alan W. Irwin > *Cc:* plp...@li... > *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...@be...> > 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. > |
From: Alan W. I. <ir...@be...> - 2014-08-27 16:15:22
|
To Arjen and Irena: On 2014-08-27 10:41-0400 Irena Johnson wrote: > 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! @Arjen: Please go ahead and push your workaround to the master branch of our git repository with a code comment that splitting up the module and subroutine this way is required to work around a pgf-13.6 bug. After all, that is a rather minor change, and others may want to use this version of the Portland Group compilers as well without having to upgrade to Davide's version 13.10. @Irena: that is excellent news indeed that Arjen's workaround solved the remaining build issue for you. However, from Davide's results (where version 13.10 does not need this workaround) it sounds like the Portland Group version 13.6 compilers are a little iffy. Therefore I suggest to gain some confidence in results for those that you do some comprehensive run-time tests. (You should run these tests every time you are using a new compiler or new compiler version.) The comprehensive test directions (I go into detail since they are suitable for anyone here who wants to test all is well with their PLplot build) are as follows: Add the cmake command-line option -DBUILD_TEST=ON which instructs cmake to configure many build-tree run-time tests. After cmake completes then run make -j4 VERBOSE=1 test_noninteractive >& test_noninteractive.out which builds and runs each of our 33 standard examples for all languages that are enabled plus a number of additional noninteractive tests. N.B. My high-quality but still 5-yr old PC takes ~8 minutes to run this test and produces some 4GB (!) of output plot files. You should check the resulting test_noninteractive.out file for any run-time errors. (I just did that which confirms that our current git master version is working well.) And you can also sample some of those resulting PostScript files using gv, For example, gv --orientation=landscape examples/test_examples_output_dir/x08f95.psc views the PostScript results of our 8th standard example written in Fortran 95. An additional test that you should run is make -j4 VERBOSE=1 test_interactive >& test_interactive.out which tests all our interactive devices for our standard examples as well as many other interactive tests. Unlike the test_noninteractive target, this target does not have to store plot results so does not chew up disk space. But you do have to interact with a number of those examples (typically by hitting the enter key) to keep them moving along. When you finish with this test, you should also check test_interactive.out for any run-time errors. Good luck with these essential comprehensive run-time tests, and please report back here if the resulting *.out files show any issues. 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...> - 2014-08-28 08:14:34
|
Hi Alan, Irena, I will make these changes - they should have no impact, except keep that version of the PG compiler happy, but at the moment I am trying to make sure my laptop stays alive :(. It was not starting up correctly - possibly a hard disk problem. Regards, Arjen > -----Original Message----- > From: Alan W. Irwin [mailto:ir...@be...] > Sent: Wednesday, August 27, 2014 6:15 PM > To: Irena Johnson > Cc: Arjen Markus; plp...@li... > Subject: Re: [Plplot-general] continuation lines in bindings/tcl/plplot_parameters.h > > To Arjen and Irena: > > On 2014-08-27 10:41-0400 Irena Johnson wrote: > > > 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! > > @Arjen: Please go ahead and push your workaround to the master branch of our git > repository with a code comment that splitting up the module and subroutine this way > is required to work around a pgf-13.6 bug. After all, that is a rather minor change, > and others may want to use this version of the Portland Group compilers as well > without having to upgrade to Davide's version 13.10. > > @Irena: that is excellent news indeed that Arjen's workaround solved the remaining > build issue for you. However, from Davide's results (where version 13.10 does not > need this workaround) it sounds like the Portland Group version 13.6 compilers are a > little iffy. Therefore I suggest to gain some confidence in results for those that you do > some comprehensive run-time tests. (You should run these tests every time you are > using a new compiler or new compiler version.) > > The comprehensive test directions (I go into detail since they are suitable for anyone > here who wants to test all is well with their PLplot build) are as follows: > > Add the cmake command-line option -DBUILD_TEST=ON which instructs cmake to > configure many build-tree run-time tests. > > After cmake completes then run > > make -j4 VERBOSE=1 test_noninteractive >& test_noninteractive.out > > which builds and runs each of our 33 standard examples for all languages that are > enabled plus a number of additional noninteractive tests. > > N.B. My high-quality but still 5-yr old PC takes ~8 minutes to run this test and > produces some 4GB (!) of output plot files. > > You should check the resulting test_noninteractive.out file for any run-time errors. (I > just did that which confirms that our current git master version is working well.) And > you can also sample some of those resulting PostScript files using gv, For example, > > gv --orientation=landscape examples/test_examples_output_dir/x08f95.psc > > views the PostScript results of our 8th standard example written in Fortran 95. > > An additional test that you should run is > > make -j4 VERBOSE=1 test_interactive >& test_interactive.out > > which tests all our interactive devices for our standard examples as well as many > other interactive tests. Unlike the test_noninteractive target, this target does not > have to store plot results so does not chew up disk space. But you do have to > interact with a number of those examples (typically by hitting the enter key) to keep > them moving along. When you finish with this test, you should also check > test_interactive.out for any run-time errors. > > Good luck with these essential comprehensive run-time tests, and please report back > here if the resulting *.out files show any issues. > > 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: Irena J. <ijo...@pp...> - 2014-08-27 18:58:33
|
Alan, I will do the run-time testing -- thank you for the detailed info! I do have one more question: it seems that I do not have the static libraries built under plplot (I only have the shared libraries -- can fortran use these libraries?). Is there a flag I should set at configuration time? Thank you, -- Irena On Wed, Aug 27, 2014 at 12:15 PM, Alan W. Irwin <ir...@be...> wrote: > To Arjen and Irena: > > > On 2014-08-27 10:41-0400 Irena Johnson wrote: > > 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! >> > > @Arjen: Please go ahead and push your workaround to the master > branch of our git repository with a code comment that splitting up the > module and subroutine this way is required to work around a pgf-13.6 > bug. After all, that is a rather minor change, and others may want to > use this version of the Portland Group compilers as well without > having to upgrade to Davide's version 13.10. > > @Irena: that is excellent news indeed that Arjen's workaround solved > the remaining build issue for you. However, from Davide's results > (where version 13.10 does not need this workaround) it sounds like the > Portland Group version 13.6 compilers are a little iffy. Therefore I > suggest to gain some confidence in results for those that you do some > comprehensive run-time tests. (You should run these tests > every time you are using a new compiler or new compiler version.) > > The comprehensive test directions (I go into detail since they are > suitable for anyone here who wants to test all is well with their > PLplot build) are as follows: > > Add the cmake command-line option -DBUILD_TEST=ON which instructs > cmake to configure many build-tree run-time tests. > > After cmake completes then run > > make -j4 VERBOSE=1 test_noninteractive >& test_noninteractive.out > > which builds and runs each of our 33 standard examples for all > languages that are enabled plus a number of additional noninteractive > tests. > > N.B. My high-quality but still 5-yr old PC takes ~8 minutes to > run this test and produces some 4GB (!) of output plot files. > > You should check the resulting test_noninteractive.out file for any > run-time errors. (I just did that which confirms that our current git > master version is working well.) And you can also sample some of those > resulting PostScript files using gv, For example, > > gv --orientation=landscape examples/test_examples_output_dir/x08f95.psc > > views the PostScript results of our 8th standard example written > in Fortran 95. > > An additional test that you should run is > > make -j4 VERBOSE=1 test_interactive >& test_interactive.out > > which tests all our interactive devices for our standard examples as > well as many other interactive tests. Unlike the test_noninteractive > target, this target does not have to store plot results so does not > chew up disk space. But you do have to interact with a number of > those examples (typically by hitting the enter key) to keep them > moving along. When you finish with this test, you should also check > test_interactive.out for any run-time errors. > > Good luck with these essential comprehensive run-time tests, and > please report back here if the resulting *.out files show any issues. > > > 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: Alan W. I. <ir...@be...> - 2014-08-27 19:41:27
|
On 2014-08-27 14:58-0400 Irena Johnson wrote: > Alan, > > I will do the run-time testing -- thank you for the detailed info! > > I do have one more question: it seems that I do not have the static > libraries built under plplot (I only have the shared libraries -- can > fortran use these libraries?). Yes, Fortran can use these shared libraries. In fact the run-time testing I suggested (and just completed for git master) does exactly that with our standard Fortran 95 examples (for the gfortran/gcc case, see further comments about the PG case below). > Is there a flag I should set at > configuration time? The VERBOSE=1 make option outputs every flag used in compilation for CMake-generated Makefiles such as these based on internal knowlege CMake has about what is required for the PG compilers you are using. So look up the relevant part of compiling the Fortran 95 examples in the run-time test *.out files (assuming those run-time tests work), and that tells you all the flags you need to use. Alternative more sophisticated ways to get the compile and link flags you need for your applications in the PG case can be determined from "make install" results which along with everything else installs both a simple CMake-based build system for the installed examples as well as a more traditional (Makefile + pkg-config) build system for those installed examples. Big caveat. Whatever method you use to obtain the necessary compile and link flags for your applications, you might find an issue for the PG compilers since as far as I know you are the first in a long time to try those compilers for the PLplot case. But we will attempt to fix such bugs so long as you continue to give us details about any issues you find. 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: Irena J. <ijo...@pp...> - 2014-09-22 19:47:14
|
Hello Alan, Please find below the errors I am getting when I ran the comprehensive run-time tests. Scanning dependencies of target tcl_examples Scanning dependencies of target x07c Scanning dependencies of target x13c Scanning dependencies of target x08c [ 0%] [ 0%] Building C object c/CMakeFiles/x07c.dir/x07c.c.o [ 8%] Building C object c/CMakeFiles/x13c.dir/x13c.c.o Building C object c/CMakeFiles/x08c.dir/x08c.c.o [ 39%] Built target tcl_examples Scanning dependencies of target x34c [ 39%] Building C object c/CMakeFiles/x34c.dir/x34c.c.o Linking C executable x13c Linking C executable x07c /usr/bin/ld: cannot find -lplplot make[3]: *** [c/x13c] Error 2 make[2]: *** [c/CMakeFiles/x13c.dir/all] Error 2 make[2]: *** Waiting for unfinished jobs.... /usr/bin/ld: cannot find -lplplot make[3]: *** [c/x07c] Error 2 make[2]: *** [c/CMakeFiles/x07c.dir/all] Error 2 Linking C executable x08c /usr/bin/ld: cannot find -lplplot make[3]: *** [c/x08c] Error 2 make[2]: *** [c/CMakeFiles/x08c.dir/all] Error 2 Linking C executable x34c /usr/bin/ld: cannot find -lplplot make[3]: *** [c/x34c] Error 2 make[2]: *** [c/CMakeFiles/x34c.dir/all] Error 2 make[1]: *** [CMakeFiles/test_diff_psc.dir/rule] Error 2 make: *** [test_diff_psc] Error 2 Scanning dependencies of target x33c Linking C executable x13c Linking C executable x07c Linking C executable x08c [ 1%] Building C object c/CMakeFiles/x33c.dir/x33c.c.o /usr/bin/ld: cannot find -lplplot /usr/bin/ld: cannot find -lplplot /usr/bin/ld: cannot find -lplplot make[3]: *** [c/x07c] Error 2 make[2]: *** [c/CMakeFiles/x07c.dir/all] Error 2 make[2]: *** Waiting for unfinished jobs.... make[3]: *** [c/x08c] Error 2 make[2]: *** [c/CMakeFiles/x08c.dir/all] Error 2 make[3]: *** [c/x13c] Error 2 make[2]: *** [c/CMakeFiles/x13c.dir/all] Error 2 Linking C executable x33c /usr/bin/ld: cannot find -lplplot make[3]: *** [c/x33c] Error 2 make[2]: *** [c/CMakeFiles/x33c.dir/all] Error 2 make[1]: *** [CMakeFiles/test_noninteractive.dir/rule] Error 2 make: *** [test_noninteractive] Error 2 Linking C executable x33c Linking C executable x13c Linking C executable x07c Linking C executable x08c /usr/bin/ld: cannot find -lplplot /usr/bin/ld: cannot find -lplplot make[3]: *** [c/x33c] Error 2 make[2]: *** [c/CMakeFiles/x33c.dir/all] Error 2 make[2]: *** Waiting for unfinished jobs.... make[3]: *** [c/x13c] Error 2 make[2]: *** [c/CMakeFiles/x13c.dir/all] Error 2 /usr/bin/ld: cannot find -lplplot /usr/bin/ld: cannot find -lplplot make[3]: *** [c/x08c] Error 2 make[2]: *** [c/CMakeFiles/x08c.dir/all] Error 2 make[3]: *** [c/x07c] Error 2 make[2]: *** [c/CMakeFiles/x07c.dir/all] Error 2 make[1]: *** [CMakeFiles/test_interactive.dir/rule] Error 2 make: *** [test_interactive] Error 2 Thanks, Irena On Wed, Aug 27, 2014 at 3:41 PM, Alan W. Irwin <ir...@be...> wrote: > On 2014-08-27 14:58-0400 Irena Johnson wrote: > > Alan, >> >> I will do the run-time testing -- thank you for the detailed info! >> >> I do have one more question: it seems that I do not have the static >> libraries built under plplot (I only have the shared libraries -- can >> fortran use these libraries?). >> > > Yes, Fortran can use these shared libraries. In fact the run-time > testing I suggested (and just completed for git master) does exactly > that with our standard Fortran 95 examples (for the gfortran/gcc case, > see further comments about the PG case below). > > Is there a flag I should set at >> configuration time? >> > > The VERBOSE=1 make option outputs every flag used in compilation for > CMake-generated Makefiles such as these based on internal knowlege > CMake has about what is required for the PG compilers you are using. > So look up the relevant part of compiling the Fortran 95 examples in > the run-time test *.out files (assuming those run-time tests work), > and that tells you all the flags you need to use. Alternative more > sophisticated ways to get the compile and link flags you need for your > applications in the PG case can be determined from "make install" > results which along with everything else installs both a simple > CMake-based build system for the installed examples as well as a more > traditional (Makefile + pkg-config) build system for those installed > examples. > > Big caveat. Whatever method you use to obtain the necessary compile > and link flags for your applications, you might find an issue for the > PG compilers since as far as I know you are the first in a long time > to try those compilers for the PLplot case. But we will attempt to > fix such bugs so long as you continue to give us details about > any issues you find. > > > 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 > __________________________ > -- Irena |
From: Alan W. I. <ir...@be...> - 2014-09-22 21:02:43
|
On 2014-09-22 15:47-0400 Irena Johnson wrote: > Hello Alan, > > Please find below the errors I am getting when I ran the comprehensive > run-time tests. > > Scanning dependencies of target tcl_examples > Scanning dependencies of target x07c > Scanning dependencies of target x13c > Scanning dependencies of target x08c > [ 0%] [ 0%] Building C object c/CMakeFiles/x07c.dir/x07c.c.o > [ 8%] Building C object c/CMakeFiles/x13c.dir/x13c.c.o > Building C object c/CMakeFiles/x08c.dir/x08c.c.o > [ 39%] Built target tcl_examples > Scanning dependencies of target x34c > [ 39%] Building C object c/CMakeFiles/x34c.dir/x34c.c.o > Linking C executable x13c > Linking C executable x07c > /usr/bin/ld: cannot find -lplplot [...] Hi Irena: It looks to me from the above results that the C examples are failing to link, but I thought you tested that case before? Anyhow, to test that case without anything else getting in the way, please give me VERBOSE=1 results for the non-parallel build case for a fresh build tree. That is, starting with an empty build tree use cmake <your usual options including -DBUILD_TEST=ON...> \ <path to PLplot source tree...> \ >& cmake.out followed by _just_ make VERBOSE=1 x01c >& make.out Then, assuming the make.out result does show the same link error as above, please compress those cmake.out and make.out files (and also the resulting CMakeCache.txt file), and send those three compressed files to this list as attachments. Once we have those details, it will make it much easier for us to figure out exactly what is going wrong. 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: Alan W. I. <ir...@be...> - 2014-08-26 20:21:54
|
On 2014-08-26 14:35-0400 Irena Johnson wrote: > Hello, > > I am trying to compile plplot-5.10.0 for PGF-13.6 and am getting the > following error: > > $ make 2>&1 |tee log.make > [ 0%] Built target deltaT-gen > [ 1%] Built target deltaT.h_built > [ 2%] Built target tai-utc-gen > [ 2%] Built target tai-utc.h_built > [ 2%] Built target qsastime > [ 2%] Built target plhershey-unicode-gen > [ 2%] Built target plhershey-unicode.h_built > [ 3%] Building C object > src/CMakeFiles/plplotd.dir/__/bindings/tcl/tclAPI.c.o > PGC-F-0223-String too long > (/pfs/tmp/ijohnson/plplot-5.10.0/bindings/tcl/plplot_parameters.h: 15) > PGC/x86-64 Linux 13.6-0: compilation aborted > make[2]: *** [src/CMakeFiles/plplotd.dir/__/bindings/tcl/tclAPI.c.o] Error 2 > make[1]: *** [src/CMakeFiles/plplotd.dir/all] Error 2 > make: *** [all] Error 2 > > > Could you please advise? Thank you! Hi Irena: I have changed the subject line to something more appropriate. Note, a quick workaround for any problem like this is to disable the relevant PLplot component. So I suggest trying the cmake option -DENABLE_tcl=OFF to avoid compiling anything to do with Tcl including bindings/tcl/tclAPI.c. (For quick one-line annotation of each of the PLplot components look for the string ENABLE in CMakeCache.txt.) 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. 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: Alan W. I. <ir...@be...> - 2014-08-26 23:00:45
|
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 __________________________ |
From: Irena J. <ijo...@pp...> - 2014-08-27 13:13:34
|
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...@be...> 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 > __________________________ > |
From: Arjen M. <Arj...@de...> - 2014-08-27 13:22:32
|
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:ijo...@pp...] Sent: Wednesday, August 27, 2014 2:43 PM To: Alan W. Irwin Cc: plp...@li... 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...@be...<mailto:ir...@be...>> 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<http://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<http://astrowww.phys.uvic.ca>). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net<http://freeeos.sf.net>); the Time Ephemerides project (timeephem.sf.net<http://timeephem.sf.net>); PLplot scientific plotting software package (plplot.sf.net<http://plplot.sf.net>); the libLASi project (unifont.org/lasi<http://unifont.org/lasi>); the Loads of Linux Links project (loll.sf.net<http://loll.sf.net>); and the Linux Brochure Project (lbproject.sf.net<http://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: Irena J. <ijo...@pp...> - 2014-08-27 13:55:26
|
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 <Arj...@de...> 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:ijo...@pp...] > *Sent:* Wednesday, August 27, 2014 2:43 PM > *To:* Alan W. Irwin > *Cc:* plp...@li... > *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...@be...> > 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. > |