From: RCY <re...@ya...> - 2013-06-27 17:44:13
|
Hi, I am trying to build the development version of plplot with octave bindings. However I get numerous errors. Is the version incompatible with later versions of octave? Thanks [ 71%] Building CXX object bindings/octave/CMakeFiles/plplot_octave.dir/plplot_octaveOCTAVE_wrap.cxx.o In file included from /usr/local/include/octave-3.7.5/octave/dim-vector.h:35:0, from /usr/local/include/octave-3.7.5/octave/Array.h:35, from /usr/local/include/octave-3.7.5/octave/boolMatrix.h:27, from /usr/local/include/octave-3.7.5/octave/mx-base.h:32, from /usr/local/include/octave-3.7.5/octave/Matrix.h:30, from /usr/local/include/octave-3.7.5/octave/oct.h:33, from /home/rc/Downloads/plplot/build/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:154: /usr/local/include/octave-3.7.5/octave/oct-refcount.h:27:3: error: #error "The file <octave/config.h> must be included before oct-refcount.h." In file included from /usr/local/include/octave-3.7.5/octave/mx-base.h:28:0, from /usr/local/include/octave-3.7.5/octave/Matrix.h:30, from /usr/local/include/octave-3.7.5/octave/oct.h:33, from /home/rc/Downloads/plplot/build/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:154: /usr/local/include/octave-3.7.5/octave/MatrixType.h:36:1: error: variable ‘OCTAVE_API MatrixType’ has initializer but incomplete type /usr/local/include/octave-3.7.5/octave/MatrixType.h:36:1: warning: extended initializer lists only available with -std=c++11 or -std=gnu++11 [enabled by default] /usr/local/include/octave-3.7.5/octave/MatrixType.h:38:1: error: expected primary-expression before ‘public’ /usr/local/include/octave-3.7.5/octave/MatrixType.h:38:1: error: expected ‘}’ before ‘public’ /usr/local/include/octave-3.7.5/octave/MatrixType.h:38:1: error: expected ‘,’ or ‘;’ before ‘public’ /usr/local/include/octave-3.7.5/octave/MatrixType.h:56:20: error: expected constructor, destructor, or type conversion before ‘;’ token /usr/local/include/octave-3.7.5/octave/MatrixType.h:58:21: error: ‘MatrixType’ does not name a type |
From: Orion P. <or...@co...> - 2013-12-28 23:53:35
|
On 06/27/2013 11:44 AM, RCY wrote: > Hi, > I am trying to build the development version of plplot with octave > bindings. However I get numerous errors. > Is the version incompatible with later versions of octave? > > Thanks > > [ 71%] Building CXX object > bindings/octave/CMakeFiles/plplot_octave.dir/plplot_octaveOCTAVE_wrap.cxx.o > In file included from /usr/local/include/octave-3.7.5/octave/dim-vector.h:35:0, > from /usr/local/include/octave-3.7.5/octave/Array.h:35, > from /usr/local/include/octave-3.7.5/octave/boolMatrix.h:27, > from /usr/local/include/octave-3.7.5/octave/mx-base.h:32, > from /usr/local/include/octave-3.7.5/octave/Matrix.h:30, > from /usr/local/include/octave-3.7.5/octave/oct.h:33, > from > /home/rc/Downloads/plplot/build/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:154: > /usr/local/include/octave-3.7.5/octave/oct-refcount.h:27:3: error: > #error "The file <octave/config.h> must be included before > oct-refcount.h." > In file included from /usr/local/include/octave-3.7.5/octave/mx-base.h:28:0, > from /usr/local/include/octave-3.7.5/octave/Matrix.h:30, > from /usr/local/include/octave-3.7.5/octave/oct.h:33, > from > /home/rc/Downloads/plplot/build/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:154: > /usr/local/include/octave-3.7.5/octave/MatrixType.h:36:1: error: > variable ‘OCTAVE_API MatrixType’ has initializer but incomplete type > /usr/local/include/octave-3.7.5/octave/MatrixType.h:36:1: warning: > extended initializer lists only available with -std=c++11 or > -std=gnu++11 [enabled by default] > /usr/local/include/octave-3.7.5/octave/MatrixType.h:38:1: error: > expected primary-expression before ‘public’ > /usr/local/include/octave-3.7.5/octave/MatrixType.h:38:1: error: > expected ‘}’ before ‘public’ > /usr/local/include/octave-3.7.5/octave/MatrixType.h:38:1: error: > expected ‘,’ or ‘;’ before ‘public’ > /usr/local/include/octave-3.7.5/octave/MatrixType.h:56:20: error: > expected constructor, destructor, or type conversion before ‘;’ token > /usr/local/include/octave-3.7.5/octave/MatrixType.h:58:21: error: > ‘MatrixType’ does not name a type I'm seeing the same now with octave 3.8.0-rc2. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane or...@co... Boulder, CO 80301 http://www.cora.nwra.com |
From: Alan W. I. <ir...@be...> - 2013-12-29 05:49:09
|
On 2013-12-28 16:53-0700 Orion Poplawski wrote: > On 06/27/2013 11:44 AM, RCY wrote: >> Hi, >> I am trying to build the development version of plplot with octave >> bindings. However I get numerous errors. >> Is the version incompatible with later versions of octave? >> >> Thanks >> >> [ 71%] Building CXX object >> bindings/octave/CMakeFiles/plplot_octave.dir/plplot_octaveOCTAVE_wrap.cxx.o >> In file included from /usr/local/include/octave-3.7.5/octave/dim-vector.h:35:0, >> from /usr/local/include/octave-3.7.5/octave/Array.h:35, >> from /usr/local/include/octave-3.7.5/octave/boolMatrix.h:27, >> from /usr/local/include/octave-3.7.5/octave/mx-base.h:32, >> from /usr/local/include/octave-3.7.5/octave/Matrix.h:30, >> from /usr/local/include/octave-3.7.5/octave/oct.h:33, >> from >> /home/rc/Downloads/plplot/build/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:154: >> /usr/local/include/octave-3.7.5/octave/oct-refcount.h:27:3: error: >> #error "The file <octave/config.h> must be included before >> oct-refcount.h." >> In file included from /usr/local/include/octave-3.7.5/octave/mx-base.h:28:0, >> from /usr/local/include/octave-3.7.5/octave/Matrix.h:30, >> from /usr/local/include/octave-3.7.5/octave/oct.h:33, >> from >> /home/rc/Downloads/plplot/build/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:154: >> /usr/local/include/octave-3.7.5/octave/MatrixType.h:36:1: error: >> variable ‘OCTAVE_API MatrixType’ has initializer but incomplete type >> /usr/local/include/octave-3.7.5/octave/MatrixType.h:36:1: warning: >> extended initializer lists only available with -std=c++11 or >> -std=gnu++11 [enabled by default] >> /usr/local/include/octave-3.7.5/octave/MatrixType.h:38:1: error: >> expected primary-expression before ‘public’ >> /usr/local/include/octave-3.7.5/octave/MatrixType.h:38:1: error: >> expected ‘}’ before ‘public’ >> /usr/local/include/octave-3.7.5/octave/MatrixType.h:38:1: error: >> expected ‘,’ or ‘;’ before ‘public’ >> /usr/local/include/octave-3.7.5/octave/MatrixType.h:56:20: error: >> expected constructor, destructor, or type conversion before ‘;’ token >> /usr/local/include/octave-3.7.5/octave/MatrixType.h:58:21: error: >> ‘MatrixType’ does not name a type > > > I'm seeing the same now with octave 3.8.0-rc2. Hi Orion and RCY: @RCY: if you want to write further comments to this list discussion (which I presume will be on-going) you are required but also most welcome to subscribe to this list. However, I am sure everyone will be happy to CC you (like I have) if you decide not to subscribe and simply want to read the further discussion without writing comments of your own. @Orion: Thanks for that report for an octave 3.8.0 release candidate. I notice the final version of octave 3.8.0 was released just today. (see ftp://ftp.gnu.org/gnu/octave). Once that version becomes available on Fedora could you confirm you are still seeing the same issue? I was intrigued by the >> #error "The file <octave/config.h> must be included before >> oct-refcount.h." message. From our swig-generated code, bindings/octave/plplot_octaveOCTAVE_wrap.cxx, this message is coming from #include <octave/oct.h> which is _the first_ octave-related include in that source code. So I don't think this error has anything to do with us unless there is a new Octave 3.8.0 requirement (which I think would be unlikely) to include a different octave header before octave/oct.h. For your further information, Andrew's and my extensive tests of our octave bindings and examples for PLplot-5.9.11 were fine. Andrew tested that PLplot release on both Debian unstable and Ubuntu Saucy (both of which have Octave-3.6.4) and I tested on Debian stable (Octave version 3.6.2). Thus, it appears to me that since the above first octave include worked fine for those versions of octave yet errors out for octave-3.8.0, that it is highly probable all the above messages are due to an internal error in octave-3.8.0 itself which might or might not be sorted out by 3.8.0 final. If it is not sorted out by 3.8.0 final, then you might want to try a simple test of compiling code consisting of the single #include statement above. Assuming that errors out the same way, then that simple test could be used as the core of a report to the Octave developers to see what they say about the issue. 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: Orion P. <or...@co...> - 2013-12-29 15:41:44
|
On 12/28/2013 10:49 PM, Alan W. Irwin wrote: > On 2013-12-28 16:53-0700 Orion Poplawski wrote: > >> On 06/27/2013 11:44 AM, RCY wrote: >>> Hi, >>> I am trying to build the development version of plplot with octave >>> bindings. However I get numerous errors. >>> Is the version incompatible with later versions of octave? >>> >>> Thanks >>> >>> [ 71%] Building CXX object >>> bindings/octave/CMakeFiles/plplot_octave.dir/plplot_octaveOCTAVE_wrap.cxx.o >>> >>> In file included from >>> /usr/local/include/octave-3.7.5/octave/dim-vector.h:35:0, >>> from >>> /usr/local/include/octave-3.7.5/octave/Array.h:35, >>> from >>> /usr/local/include/octave-3.7.5/octave/boolMatrix.h:27, >>> from >>> /usr/local/include/octave-3.7.5/octave/mx-base.h:32, >>> from >>> /usr/local/include/octave-3.7.5/octave/Matrix.h:30, >>> from /usr/local/include/octave-3.7.5/octave/oct.h:33, >>> from >>> /home/rc/Downloads/plplot/build/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:154: >>> >>> /usr/local/include/octave-3.7.5/octave/oct-refcount.h:27:3: error: >>> #error "The file <octave/config.h> must be included before >>> oct-refcount.h." >>> In file included from >>> /usr/local/include/octave-3.7.5/octave/mx-base.h:28:0, >>> from >>> /usr/local/include/octave-3.7.5/octave/Matrix.h:30, >>> from /usr/local/include/octave-3.7.5/octave/oct.h:33, >>> from >>> /home/rc/Downloads/plplot/build/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:154: >>> >>> /usr/local/include/octave-3.7.5/octave/MatrixType.h:36:1: error: >>> variable ‘OCTAVE_API MatrixType’ has initializer but incomplete type >>> /usr/local/include/octave-3.7.5/octave/MatrixType.h:36:1: warning: >>> extended initializer lists only available with -std=c++11 or >>> -std=gnu++11 [enabled by default] >>> /usr/local/include/octave-3.7.5/octave/MatrixType.h:38:1: error: >>> expected primary-expression before ‘public’ >>> /usr/local/include/octave-3.7.5/octave/MatrixType.h:38:1: error: >>> expected ‘}’ before ‘public’ >>> /usr/local/include/octave-3.7.5/octave/MatrixType.h:38:1: error: >>> expected ‘,’ or ‘;’ before ‘public’ >>> /usr/local/include/octave-3.7.5/octave/MatrixType.h:56:20: error: >>> expected constructor, destructor, or type conversion before ‘;’ token >>> /usr/local/include/octave-3.7.5/octave/MatrixType.h:58:21: error: >>> ‘MatrixType’ does not name a type >> >> >> I'm seeing the same now with octave 3.8.0-rc2. > > Hi Orion and RCY: > > @RCY: if you want to write further comments to this list discussion > (which I presume will be on-going) you are required but also most > welcome to subscribe to this list. However, I am sure everyone will > be happy to CC you (like I have) if you decide not to subscribe and > simply want to read the further discussion without writing comments of > your own. > > @Orion: > > Thanks for that report for an octave 3.8.0 release candidate. I > notice the final version of octave 3.8.0 was released just today. (see > ftp://ftp.gnu.org/gnu/octave). Once that version becomes available on > Fedora could you confirm you are still seeing the same issue? > > I was intrigued by the > >>> #error "The file <octave/config.h> must be included before >>> oct-refcount.h." > > message. From our swig-generated code, > bindings/octave/plplot_octaveOCTAVE_wrap.cxx, this message is > coming from > > #include <octave/oct.h> > > which is _the first_ octave-related include in that source code. So I > don't think this error has anything to do with us unless there is a > new Octave 3.8.0 requirement (which I think would be unlikely) to > include a different octave header before octave/oct.h. > > For your further information, Andrew's and my extensive tests of our > octave bindings and examples for PLplot-5.9.11 were fine. Andrew > tested that PLplot release on both Debian unstable and Ubuntu Saucy > (both of which have Octave-3.6.4) and I tested on Debian stable > (Octave version 3.6.2). > > Thus, it appears to me that since the above first octave include > worked fine for those versions of octave yet errors out for > octave-3.8.0, that it is highly probable all the above messages are > due to an internal error in octave-3.8.0 itself which might or might > not be sorted out by 3.8.0 final. > > If it is not sorted out by 3.8.0 final, then you might want to try a > simple test of compiling code consisting of the single #include > statement above. Assuming that errors out the same way, then that > simple test could be used as the core of a report to the Octave > developers to see what they say about the issue. > > Alan Still failing with 3.8.0 final: http://koji.fedoraproject.org/koji/getfile?taskID=6340306&name=build.log $ g++ -c -fPIC -I/usr/include/octave-3.8.0/octave/.. -I/usr/include/octave-3.8.0/octave -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -pthread test.cc $ cat test.cc #include <octave/oct.h> $ cat /usr/include/octave-3.8.0/octave/oct.h /* Copyright (C) 1996-2013 John W. Eaton This file is part of Octave. Octave is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 3 of the License, or (at your option) any later version. Octave is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with Octave; see the file COPYING. If not, see <http://www.gnu.org/licenses/>. */ #if !defined (octave_oct_h) #define octave_oct_h 1 // Things that are often included to create .oct files. // config.h needs to be first because it includes #defines that can */ // affect other header files. #include <config.h> #include "Matrix.h" #include "oct-locbuf.h" #include "defun-dld.h" #include "error.h" #include "gripes.h" #include "help.h" #include "oct-obj.h" #include "pager.h" #include "utils.h" #include "variables.h" #endif My guess is that you are pulling in plplot's config.h before octave's config.h: /usr/bin/c++ -DHAVE_CONFIG_H -Dplplot_octave_EXPORTS -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m32 -march=i686 -mtune=atom -fasynchronous-unwind-tables -fPIC -I/builddir/build/BUILD/plplot-5.9.10/include -I/builddir/build/BUILD/plplot-5.9.10/lib/qsastime -I/builddir/build/BUILD/plplot-5.9.10/fedora -I/builddir/build/BUILD/plplot-5.9.10/fedora/include -I/builddir/build/BUILD/plplot-5.9.10/fedora/bindings/octave -I/usr/include/octave-3.8.0 -I/usr/include/octave-3.8.0/octave -I/builddir/build/BUILD/plplot-5.9.10/bindings/swig-support -o CMakeFiles/plplot_octave.dir/plplot_octaveOCTAVE_wrap.cxx.o -c /builddir/build/BUILD/plplot-5.9.10/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx In file included from /usr/include/octave-3.8.0/octave/dim-vector.h:35:0, from /usr/include/octave-3.8.0/octave/Array.h:35, from /usr/include/octave-3.8.0/octave/boolMatrix.h:27, from /usr/include/octave-3.8.0/octave/mx-base.h:32, from /usr/include/octave-3.8.0/octave/Matrix.h:30, from /usr/include/octave-3.8.0/octave/oct.h:33, from /builddir/build/BUILD/plplot-5.9.10/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:154: /usr/include/octave-3.8.0/octave/oct-refcount.h:27:3: error: #error "The file <octave/config.h> must be included before oct-refcount.h." # error "The file <octave/config.h> must be included before oct-refcount.h." ^ So you probably need to include <octave/config.h> first, but you could certainly argue that octave's header should use <octave/config.h> as well - although that would be a large undertaking. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane or...@co... Boulder, CO 80301 http://www.cora.nwra.com |
From: Alan W. I. <ir...@be...> - 2013-12-29 18:00:31
|
On 2013-12-29 08:41-0700 Orion Poplawski wrote: > On 12/28/2013 10:49 PM, Alan W. Irwin wrote: >> On 2013-12-28 16:53-0700 Orion Poplawski wrote: >> >>> On 06/27/2013 11:44 AM, RCY wrote: >>>> Hi, >>>> I am trying to build the development version of plplot with octave >>>> bindings. However I get numerous errors. >>>> Is the version incompatible with later versions of octave? >>>> >>>> Thanks >>>> >>>> [ 71%] Building CXX object >>>> bindings/octave/CMakeFiles/plplot_octave.dir/plplot_octaveOCTAVE_wrap.cxx.o >>>> >>>> In file included from >>>> /usr/local/include/octave-3.7.5/octave/dim-vector.h:35:0, >>>> from >>>> /usr/local/include/octave-3.7.5/octave/Array.h:35, >>>> from >>>> /usr/local/include/octave-3.7.5/octave/boolMatrix.h:27, >>>> from >>>> /usr/local/include/octave-3.7.5/octave/mx-base.h:32, >>>> from >>>> /usr/local/include/octave-3.7.5/octave/Matrix.h:30, >>>> from /usr/local/include/octave-3.7.5/octave/oct.h:33, >>>> from >>>> /home/rc/Downloads/plplot/build/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:154: >>>> >>>> /usr/local/include/octave-3.7.5/octave/oct-refcount.h:27:3: error: >>>> #error "The file <octave/config.h> must be included before >>>> oct-refcount.h." >>>> In file included from >>>> /usr/local/include/octave-3.7.5/octave/mx-base.h:28:0, >>>> from >>>> /usr/local/include/octave-3.7.5/octave/Matrix.h:30, >>>> from /usr/local/include/octave-3.7.5/octave/oct.h:33, >>>> from >>>> /home/rc/Downloads/plplot/build/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:154: >>>> >>>> /usr/local/include/octave-3.7.5/octave/MatrixType.h:36:1: error: >>>> variable ‘OCTAVE_API MatrixType’ has initializer but incomplete type >>>> /usr/local/include/octave-3.7.5/octave/MatrixType.h:36:1: warning: >>>> extended initializer lists only available with -std=c++11 or >>>> -std=gnu++11 [enabled by default] >>>> /usr/local/include/octave-3.7.5/octave/MatrixType.h:38:1: error: >>>> expected primary-expression before ‘public’ >>>> /usr/local/include/octave-3.7.5/octave/MatrixType.h:38:1: error: >>>> expected ‘}’ before ‘public’ >>>> /usr/local/include/octave-3.7.5/octave/MatrixType.h:38:1: error: >>>> expected ‘,’ or ‘;’ before ‘public’ >>>> /usr/local/include/octave-3.7.5/octave/MatrixType.h:56:20: error: >>>> expected constructor, destructor, or type conversion before ‘;’ token >>>> /usr/local/include/octave-3.7.5/octave/MatrixType.h:58:21: error: >>>> ‘MatrixType’ does not name a type >>> >>> >>> I'm seeing the same now with octave 3.8.0-rc2. >> >> Hi Orion and RCY: >> >> @RCY: if you want to write further comments to this list discussion >> (which I presume will be on-going) you are required but also most >> welcome to subscribe to this list. However, I am sure everyone will >> be happy to CC you (like I have) if you decide not to subscribe and >> simply want to read the further discussion without writing comments of >> your own. >> >> @Orion: >> >> Thanks for that report for an octave 3.8.0 release candidate. I >> notice the final version of octave 3.8.0 was released just today. (see >> ftp://ftp.gnu.org/gnu/octave). Once that version becomes available on >> Fedora could you confirm you are still seeing the same issue? >> >> I was intrigued by the >> >>>> #error "The file <octave/config.h> must be included before >>>> oct-refcount.h." >> >> message. From our swig-generated code, >> bindings/octave/plplot_octaveOCTAVE_wrap.cxx, this message is >> coming from >> >> #include <octave/oct.h> >> >> which is _the first_ octave-related include in that source code. So I >> don't think this error has anything to do with us unless there is a >> new Octave 3.8.0 requirement (which I think would be unlikely) to >> include a different octave header before octave/oct.h. >> >> For your further information, Andrew's and my extensive tests of our >> octave bindings and examples for PLplot-5.9.11 were fine. Andrew >> tested that PLplot release on both Debian unstable and Ubuntu Saucy >> (both of which have Octave-3.6.4) and I tested on Debian stable >> (Octave version 3.6.2). >> >> Thus, it appears to me that since the above first octave include >> worked fine for those versions of octave yet errors out for >> octave-3.8.0, that it is highly probable all the above messages are >> due to an internal error in octave-3.8.0 itself which might or might >> not be sorted out by 3.8.0 final. >> >> If it is not sorted out by 3.8.0 final, then you might want to try a >> simple test of compiling code consisting of the single #include >> statement above. Assuming that errors out the same way, then that >> simple test could be used as the core of a report to the Octave >> developers to see what they say about the issue. >> >> Alan > > > Still failing with 3.8.0 final: > > http://koji.fedoraproject.org/koji/getfile?taskID=6340306&name=build.log > > $ g++ -c -fPIC -I/usr/include/octave-3.8.0/octave/.. > -I/usr/include/octave-3.8.0/octave -O2 -g -pipe -Wall > -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions > -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches > -m64 -mtune=generic -pthread test.cc > $ cat test.cc > #include <octave/oct.h> > > $ cat /usr/include/octave-3.8.0/octave/oct.h > /* > > Copyright (C) 1996-2013 John W. Eaton > > This file is part of Octave. > > Octave is free software; you can redistribute it and/or modify it > under the terms of the GNU General Public License as published by the > Free Software Foundation; either version 3 of the License, or (at your > option) any later version. > > Octave is distributed in the hope that it will be useful, but WITHOUT > ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or > FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License > for more details. > > You should have received a copy of the GNU General Public License > along with Octave; see the file COPYING. If not, see > <http://www.gnu.org/licenses/>. > > */ > > #if !defined (octave_oct_h) > #define octave_oct_h 1 > > // Things that are often included to create .oct files. > > // config.h needs to be first because it includes #defines that can */ > // affect other header files. > > #include <config.h> > > #include "Matrix.h" > > #include "oct-locbuf.h" > #include "defun-dld.h" > #include "error.h" > #include "gripes.h" > #include "help.h" > #include "oct-obj.h" > #include "pager.h" > #include "utils.h" > #include "variables.h" > > #endif > > > My guess is that you are pulling in plplot's config.h before octave's > config.h: I think you are correct, and the root cause is a subtle change in how octave attempts to include its config.h. For 3.6.x, oct.h used #include "config.h" which meant that file (located in the same directory as oct.h for 3.6.x) is always safely found without clashing with other config.h files. But now I think the Octave developers have made a somewhat irresponsible choice for how they handle config.h for 3.8.0. They changed oct.h (see above) to use the angle-bracket form #include <config.h> which means the compiler is allowed to look everywhere for config.h that is allowed by the -I switch order which is much less safe against name clashes (e.g., with PLplot's config.h) and also now requires two -I switches to find all the Octave headers assuming the new location of config.h is /usr/include/octave-3.8.0 rather than /usr/include/octave-3.8.0/octave. <aside> Both above and below your -I switches point to _both_ /usr/include/octave-3.8.0/ and /usr/include/octave-3.8.0/octave which suggests the new location (for 3.8.0) for config.h might be /usr/include/octave-3.8.0/. (Note on my Debian stable system /usr/include/octave-3.6.2/ has nothing in it but the octave subdirectory so there is no need for those two different -I switches.) </aside> > > /usr/bin/c++ -DHAVE_CONFIG_H -Dplplot_octave_EXPORTS -O2 -g -pipe > -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions > -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches > -m32 -march=i686 -mtune=atom -fasynchronous-unwind-tables -fPIC > -I/builddir/build/BUILD/plplot-5.9.10/include > -I/builddir/build/BUILD/plplot-5.9.10/lib/qsastime > -I/builddir/build/BUILD/plplot-5.9.10/fedora > -I/builddir/build/BUILD/plplot-5.9.10/fedora/include > -I/builddir/build/BUILD/plplot-5.9.10/fedora/bindings/octave > -I/usr/include/octave-3.8.0 -I/usr/include/octave-3.8.0/octave > -I/builddir/build/BUILD/plplot-5.9.10/bindings/swig-support -o > CMakeFiles/plplot_octave.dir/plplot_octaveOCTAVE_wrap.cxx.o -c > /builddir/build/BUILD/plplot-5.9.10/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx > In file included from /usr/include/octave-3.8.0/octave/dim-vector.h:35:0, > from /usr/include/octave-3.8.0/octave/Array.h:35, > from /usr/include/octave-3.8.0/octave/boolMatrix.h:27, > from /usr/include/octave-3.8.0/octave/mx-base.h:32, > from /usr/include/octave-3.8.0/octave/Matrix.h:30, > from /usr/include/octave-3.8.0/octave/oct.h:33, > from > /builddir/build/BUILD/plplot-5.9.10/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:154: > /usr/include/octave-3.8.0/octave/oct-refcount.h:27:3: error: #error "The > file <octave/config.h> must be included before oct-refcount.h." > # error "The file <octave/config.h> must be included before > oct-refcount.h." > ^ I frankly don't understand how the above is finding PLplot's config.h which should be located in the top directory of the build tree which I infer is /builddir/build/BUILD/plplot-5.9.10 in the above case. But none of the above -I switches point to that location. So I may be missing something. But if -I/builddir/build/BUILD/plplot-5.9.10 came before -I/usr/include/octave-3.8.0, then the compiler would pick the Plplot version of config.h to use for both PLplot and octave, and if the order were reversed, the compiler would pick the Octave version of config.h to use for both PLplot and octave. Regardless of the one -I switch detail above which I don't understand, this issue shows there is very likely a name clash with octave-3.8.0 now and potentially with other packages as well in the future so the only proper solution to this issue is to rename the PLplot config.h to a less generic name. More later after I implement and test that change. 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: Orion P. <or...@co...> - 2013-12-29 18:18:53
|
On 12/29/2013 11:00 AM, Alan W. Irwin wrote: > On 2013-12-29 08:41-0700 Orion Poplawski wrote: > >> On 12/28/2013 10:49 PM, Alan W. Irwin wrote: >>> On 2013-12-28 16:53-0700 Orion Poplawski wrote: >>> >>>> On 06/27/2013 11:44 AM, RCY wrote: >>>>> Hi, >>>>> I am trying to build the development version of plplot with octave >>>>> bindings. However I get numerous errors. >>>>> Is the version incompatible with later versions of octave? >>>>> >>>>> Thanks >>>>> >>>>> [ 71%] Building CXX object >>>>> bindings/octave/CMakeFiles/plplot_octave.dir/plplot_octaveOCTAVE_wrap.cxx.o >>>>> >>>>> >>>>> In file included from >>>>> /usr/local/include/octave-3.7.5/octave/dim-vector.h:35:0, >>>>> from >>>>> /usr/local/include/octave-3.7.5/octave/Array.h:35, >>>>> from >>>>> /usr/local/include/octave-3.7.5/octave/boolMatrix.h:27, >>>>> from >>>>> /usr/local/include/octave-3.7.5/octave/mx-base.h:32, >>>>> from >>>>> /usr/local/include/octave-3.7.5/octave/Matrix.h:30, >>>>> from >>>>> /usr/local/include/octave-3.7.5/octave/oct.h:33, >>>>> from >>>>> /home/rc/Downloads/plplot/build/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:154: >>>>> >>>>> >>>>> /usr/local/include/octave-3.7.5/octave/oct-refcount.h:27:3: error: >>>>> #error "The file <octave/config.h> must be included before >>>>> oct-refcount.h." >>>>> In file included from >>>>> /usr/local/include/octave-3.7.5/octave/mx-base.h:28:0, >>>>> from >>>>> /usr/local/include/octave-3.7.5/octave/Matrix.h:30, >>>>> from >>>>> /usr/local/include/octave-3.7.5/octave/oct.h:33, >>>>> from >>>>> /home/rc/Downloads/plplot/build/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:154: >>>>> >>>>> >>>>> /usr/local/include/octave-3.7.5/octave/MatrixType.h:36:1: error: >>>>> variable ‘OCTAVE_API MatrixType’ has initializer but incomplete type >>>>> /usr/local/include/octave-3.7.5/octave/MatrixType.h:36:1: warning: >>>>> extended initializer lists only available with -std=c++11 or >>>>> -std=gnu++11 [enabled by default] >>>>> /usr/local/include/octave-3.7.5/octave/MatrixType.h:38:1: error: >>>>> expected primary-expression before ‘public’ >>>>> /usr/local/include/octave-3.7.5/octave/MatrixType.h:38:1: error: >>>>> expected ‘}’ before ‘public’ >>>>> /usr/local/include/octave-3.7.5/octave/MatrixType.h:38:1: error: >>>>> expected ‘,’ or ‘;’ before ‘public’ >>>>> /usr/local/include/octave-3.7.5/octave/MatrixType.h:56:20: error: >>>>> expected constructor, destructor, or type conversion before ‘;’ token >>>>> /usr/local/include/octave-3.7.5/octave/MatrixType.h:58:21: error: >>>>> ‘MatrixType’ does not name a type >>>> >>>> >>>> I'm seeing the same now with octave 3.8.0-rc2. >>> >>> Hi Orion and RCY: >>> >>> @RCY: if you want to write further comments to this list discussion >>> (which I presume will be on-going) you are required but also most >>> welcome to subscribe to this list. However, I am sure everyone will >>> be happy to CC you (like I have) if you decide not to subscribe and >>> simply want to read the further discussion without writing comments of >>> your own. >>> >>> @Orion: >>> >>> Thanks for that report for an octave 3.8.0 release candidate. I >>> notice the final version of octave 3.8.0 was released just today. (see >>> ftp://ftp.gnu.org/gnu/octave). Once that version becomes available on >>> Fedora could you confirm you are still seeing the same issue? >>> >>> I was intrigued by the >>> >>>>> #error "The file <octave/config.h> must be included before >>>>> oct-refcount.h." >>> >>> message. From our swig-generated code, >>> bindings/octave/plplot_octaveOCTAVE_wrap.cxx, this message is >>> coming from >>> >>> #include <octave/oct.h> >>> >>> which is _the first_ octave-related include in that source code. So I >>> don't think this error has anything to do with us unless there is a >>> new Octave 3.8.0 requirement (which I think would be unlikely) to >>> include a different octave header before octave/oct.h. >>> >>> For your further information, Andrew's and my extensive tests of our >>> octave bindings and examples for PLplot-5.9.11 were fine. Andrew >>> tested that PLplot release on both Debian unstable and Ubuntu Saucy >>> (both of which have Octave-3.6.4) and I tested on Debian stable >>> (Octave version 3.6.2). >>> >>> Thus, it appears to me that since the above first octave include >>> worked fine for those versions of octave yet errors out for >>> octave-3.8.0, that it is highly probable all the above messages are >>> due to an internal error in octave-3.8.0 itself which might or might >>> not be sorted out by 3.8.0 final. >>> >>> If it is not sorted out by 3.8.0 final, then you might want to try a >>> simple test of compiling code consisting of the single #include >>> statement above. Assuming that errors out the same way, then that >>> simple test could be used as the core of a report to the Octave >>> developers to see what they say about the issue. >>> >>> Alan >> >> >> Still failing with 3.8.0 final: >> >> http://koji.fedoraproject.org/koji/getfile?taskID=6340306&name=build.log >> >> $ g++ -c -fPIC -I/usr/include/octave-3.8.0/octave/.. >> -I/usr/include/octave-3.8.0/octave -O2 -g -pipe -Wall >> -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions >> -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches >> -m64 -mtune=generic -pthread test.cc >> $ cat test.cc >> #include <octave/oct.h> >> >> $ cat /usr/include/octave-3.8.0/octave/oct.h >> /* >> >> Copyright (C) 1996-2013 John W. Eaton >> >> This file is part of Octave. >> >> Octave is free software; you can redistribute it and/or modify it >> under the terms of the GNU General Public License as published by the >> Free Software Foundation; either version 3 of the License, or (at your >> option) any later version. >> >> Octave is distributed in the hope that it will be useful, but WITHOUT >> ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or >> FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License >> for more details. >> >> You should have received a copy of the GNU General Public License >> along with Octave; see the file COPYING. If not, see >> <http://www.gnu.org/licenses/>. >> >> */ >> >> #if !defined (octave_oct_h) >> #define octave_oct_h 1 >> >> // Things that are often included to create .oct files. >> >> // config.h needs to be first because it includes #defines that can */ >> // affect other header files. >> >> #include <config.h> >> >> #include "Matrix.h" >> >> #include "oct-locbuf.h" >> #include "defun-dld.h" >> #include "error.h" >> #include "gripes.h" >> #include "help.h" >> #include "oct-obj.h" >> #include "pager.h" >> #include "utils.h" >> #include "variables.h" >> >> #endif >> >> >> My guess is that you are pulling in plplot's config.h before octave's >> config.h: > > I think you are correct, and the root cause is a subtle change in how > octave attempts to include its config.h. For 3.6.x, oct.h used > > #include "config.h" > > which meant that file (located in the same directory as oct.h for > 3.6.x) is always safely found without clashing with other config.h > files. But now I think the Octave developers have made a somewhat > irresponsible choice > for how they handle config.h for 3.8.0. They changed oct.h (see above) > to use the angle-bracket form > > #include <config.h> > > which means the compiler is allowed to look everywhere for config.h > that is allowed by the -I switch order which is much less safe against > name clashes (e.g., with PLplot's config.h) and also now requires two -I > switches to find all the Octave headers assuming the new location of > config.h is /usr/include/octave-3.8.0 rather than > /usr/include/octave-3.8.0/octave. Ah, good catch, that may be the issue. I've filed: https://savannah.gnu.org/bugs/index.php?41027 > > <aside> > Both above and below your -I switches point to _both_ > /usr/include/octave-3.8.0/ and /usr/include/octave-3.8.0/octave which > suggests the new location (for 3.8.0) for config.h might be > /usr/include/octave-3.8.0/. (Note on my Debian stable system > /usr/include/octave-3.6.2/ has nothing in it but the octave subdirectory > so there is no need for those two different -I switches.) > </aside> > The issue is that octave using programs use <octave/oct.h> but the octave headers just use "oct.h". >> >> /usr/bin/c++ -DHAVE_CONFIG_H -Dplplot_octave_EXPORTS -O2 -g -pipe >> -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions >> -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches >> -m32 -march=i686 -mtune=atom -fasynchronous-unwind-tables -fPIC >> -I/builddir/build/BUILD/plplot-5.9.10/include >> -I/builddir/build/BUILD/plplot-5.9.10/lib/qsastime >> -I/builddir/build/BUILD/plplot-5.9.10/fedora >> -I/builddir/build/BUILD/plplot-5.9.10/fedora/include >> -I/builddir/build/BUILD/plplot-5.9.10/fedora/bindings/octave >> -I/usr/include/octave-3.8.0 -I/usr/include/octave-3.8.0/octave >> -I/builddir/build/BUILD/plplot-5.9.10/bindings/swig-support -o >> CMakeFiles/plplot_octave.dir/plplot_octaveOCTAVE_wrap.cxx.o -c >> /builddir/build/BUILD/plplot-5.9.10/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx >> >> In file included from /usr/include/octave-3.8.0/octave/dim-vector.h:35:0, >> from /usr/include/octave-3.8.0/octave/Array.h:35, >> from /usr/include/octave-3.8.0/octave/boolMatrix.h:27, >> from /usr/include/octave-3.8.0/octave/mx-base.h:32, >> from /usr/include/octave-3.8.0/octave/Matrix.h:30, >> from /usr/include/octave-3.8.0/octave/oct.h:33, >> from >> /builddir/build/BUILD/plplot-5.9.10/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:154: >> >> /usr/include/octave-3.8.0/octave/oct-refcount.h:27:3: error: #error "The >> file <octave/config.h> must be included before oct-refcount.h." >> # error "The file <octave/config.h> must be included before >> oct-refcount.h." >> ^ > > I frankly don't understand how the above is finding PLplot's config.h > which should be located in the top directory of the build tree which I > infer is /builddir/build/BUILD/plplot-5.9.10 in the above case. But > none of the above > -I switches point to that location. So I may be missing something. But > if -I/builddir/build/BUILD/plplot-5.9.10 came before > -I/usr/include/octave-3.8.0, then the compiler would pick the Plplot > version of config.h to use for both PLplot and octave, and if the order > were reversed, the compiler would pick the Octave version of config.h > to use for both PLplot and octave. Perhaps it could be some other config.h? > Regardless of the one -I switch detail above which I don't understand, > this issue shows there is very likely a name clash with octave-3.8.0 > now and potentially with other packages as well in the future so the > only proper solution to this issue is to rename the PLplot config.h to > a less generic name. > > More later after I implement and test that change. > > 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 > __________________________ -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane or...@co... Boulder, CO 80301 http://www.cora.nwra.com |
From: Alan W. I. <ir...@be...> - 2013-12-29 20:34:32
|
On 2013-12-29 11:18-0700 Orion Poplawski wrote: > On 12/29/2013 11:00 AM, Alan W. Irwin wrote: >> [...T]he root cause is a subtle change in how >> octave attempts to include its config.h. For 3.6.x, oct.h used >> >> #include "config.h" >> >> which meant that file (located in the same directory as oct.h for >> 3.6.x) is always safely found without clashing with other config.h >> files. But now I think the Octave developers have made a somewhat >> irresponsible choice >> for how they handle config.h for 3.8.0. They changed oct.h (see above) >> to use the angle-bracket form >> >> #include <config.h> >> >> which means the compiler is allowed to look everywhere for config.h >> that is allowed by the -I switch order which is much less safe against >> name clashes (e.g., with PLplot's config.h) and also now requires two -I >> switches to find all the Octave headers assuming the new location of >> config.h is /usr/include/octave-3.8.0 rather than >> /usr/include/octave-3.8.0/octave. > > Ah, good catch, that may be the issue. I've filed: > https://savannah.gnu.org/bugs/index.php?41027 > >> >> <aside> >> Both above and below your -I switches point to _both_ >> /usr/include/octave-3.8.0/ and /usr/include/octave-3.8.0/octave which >> suggests the new location (for 3.8.0) for config.h might be >> /usr/include/octave-3.8.0/. (Note on my Debian stable system >> /usr/include/octave-3.6.2/ has nothing in it but the octave subdirectory >> so there is no need for those two different -I switches.) >> </aside> >> > > The issue is that octave using programs use <octave/oct.h> but the > octave headers just use "oct.h". > >>> >>> /usr/bin/c++ -DHAVE_CONFIG_H -Dplplot_octave_EXPORTS -O2 -g -pipe >>> -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions >>> -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches >>> -m32 -march=i686 -mtune=atom -fasynchronous-unwind-tables -fPIC >>> -I/builddir/build/BUILD/plplot-5.9.10/include >>> -I/builddir/build/BUILD/plplot-5.9.10/lib/qsastime >>> -I/builddir/build/BUILD/plplot-5.9.10/fedora >>> -I/builddir/build/BUILD/plplot-5.9.10/fedora/include >>> -I/builddir/build/BUILD/plplot-5.9.10/fedora/bindings/octave >>> -I/usr/include/octave-3.8.0 -I/usr/include/octave-3.8.0/octave >>> -I/builddir/build/BUILD/plplot-5.9.10/bindings/swig-support -o >>> CMakeFiles/plplot_octave.dir/plplot_octaveOCTAVE_wrap.cxx.o -c >>> /builddir/build/BUILD/plplot-5.9.10/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx >>> >>> In file included from /usr/include/octave-3.8.0/octave/dim-vector.h:35:0, >>> from /usr/include/octave-3.8.0/octave/Array.h:35, >>> from /usr/include/octave-3.8.0/octave/boolMatrix.h:27, >>> from /usr/include/octave-3.8.0/octave/mx-base.h:32, >>> from /usr/include/octave-3.8.0/octave/Matrix.h:30, >>> from /usr/include/octave-3.8.0/octave/oct.h:33, >>> from >>> /builddir/build/BUILD/plplot-5.9.10/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:154: >>> >>> /usr/include/octave-3.8.0/octave/oct-refcount.h:27:3: error: #error "The >>> file <octave/config.h> must be included before oct-refcount.h." >>> # error "The file <octave/config.h> must be included before >>> oct-refcount.h." >>> ^ >> >> I frankly don't understand how the above is finding PLplot's config.h >> which should be located in the top directory of the build tree which I >> infer is /builddir/build/BUILD/plplot-5.9.10 in the above case. But >> none of the above >> -I switches point to that location. So I may be missing something. But >> if -I/builddir/build/BUILD/plplot-5.9.10 came before >> -I/usr/include/octave-3.8.0, then the compiler would pick the Plplot >> version of config.h to use for both PLplot and octave, and if the order >> were reversed, the compiler would pick the Octave version of config.h >> to use for both PLplot and octave. > > Perhaps it could be some other config.h? The above -I options include nothing but PLplot build tree and Octave locations. I guess there is always a change a default system header location (also checked by gcc) on Fedora could contain a config.h file, but I assume that is unlikely. Please let me know if my latest PLplot change from config.h to plplot_config.h (revision 12914) solves this issue. Of course, if it doesn't solve it, the change was worth doing anyway. And if it does solve it, I hope your bug report still convinces the Octave developers to move back to using the quoted form of #include for config.h (or better yet change the name to octave_config.h). After all, there are likely quite a few software projects still left out there that do use the config.h name (at least internally in their build tree as PLplot did up to now). 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: Orion P. <or...@co...> - 2013-12-30 03:25:51
|
On 12/29/2013 01:34 PM, Alan W. Irwin wrote: > Please let me know if my latest PLplot change from config.h to > plplot_config.h (revision 12914) solves this issue. Of course, if it > doesn't solve it, the change was worth doing anyway. And if it does > solve it, I hope your bug report still convinces the Octave developers > to move back to using the quoted form of #include for config.h (or > better yet change the name to octave_config.h). After all, there are > likely quite a few software projects still left out there that do use > the config.h name (at least internally in their build tree as PLplot > did up to now). > > Alan Alan - That does indeed get us further - but now we seem to be into the meat of the API changes in octave: /usr/bin/cmake -E cmake_progress_report /builddir/build/BUILD/plplot-5.9.11/fedora/CMakeFiles 19 [ 13%] Building CXX object bindings/octave/CMakeFiles/plplot_octave.dir/plplot_octaveOCTAVE_wrap.cxx.o cd /builddir/build/BUILD/plplot-5.9.11/fedora/bindings/octave && /usr/bin/c++ -DHAVE_CONFIG_H -Dplplot_octave_EXPORTS -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m32 -march=i686 -mtune=atom -fasynchronous-unwind-tables -fPIC -I/builddir/build/BUILD/plplot-5.9.11/include -I/builddir/build/BUILD/plplot-5.9.11/lib/qsastime -I/builddir/build/BUILD/plplot-5.9.11/fedora -I/builddir/build/BUILD/plplot-5.9.11/fedora/include -I/builddir/build/BUILD/plplot-5.9.11/fedora/bindings/octave -I/usr/include/octave-3.8.0 -I/usr/include/octave-3.8.0/octave -I/builddir/build/BUILD/plplot-5.9.11/bindings/swig-support -o CMakeFiles/plplot_octave.dir/plplot_octaveOCTAVE_wrap.cxx.o -c /builddir/build/BUILD/plplot-5.9.11/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx /builddir/build/BUILD/plplot-5.9.11/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:1507:36: warning: 'Octave_map' is deprecated (declared at /usr/include/octave-3.8.0/octave/oct-map.h:484) [-Wdeprecated-declarations] virtual Octave_map map_value() const { ^ /builddir/build/BUILD/plplot-5.9.11/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:1507:24: error: invalid covariant return type for 'virtual Octave_map octave_swig_type::map_value() const' virtual Octave_map map_value() const { ^ In file included from /usr/include/octave-3.8.0/octave/ov.h:58:0, from /usr/include/octave-3.8.0/octave/oct-obj.h:34, from /usr/include/octave-3.8.0/octave/ov-fcn.h:32, from /usr/include/octave-3.8.0/octave/ov-builtin.h:28, from /usr/include/octave-3.8.0/octave/defun-int.h:28, from /usr/include/octave-3.8.0/octave/defun-dld.h:30, from /usr/include/octave-3.8.0/octave/oct.h:36, from /builddir/build/BUILD/plplot-5.9.11/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:154: /usr/include/octave-3.8.0/octave/ov-base.h:568:22: error: overriding 'virtual octave_map octave_base_value::map_value() const' virtual octave_map map_value (void) const; ^ /builddir/build/BUILD/plplot-5.9.11/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx: In member function 'virtual dim_vector octave_swig_type::dims() const': /builddir/build/BUILD/plplot-5.9.11/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:1183:46: error: 'class octave_value' has no member named 'is_real_nd_array' } else if (out.is_matrix_type() || out.is_real_nd_array() || out.is_numeric_type() ) { ^ /builddir/build/BUILD/plplot-5.9.11/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx: At global scope: /builddir/build/BUILD/plplot-5.9.11/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:1742:36: warning: 'Octave_map' is deprecated (declared at /usr/include/octave-3.8.0/octave/oct-map.h:484) [-Wdeprecated-declarations] virtual Octave_map map_value() const ^ /builddir/build/BUILD/plplot-5.9.11/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:1742:24: error: invalid covariant return type for 'virtual Octave_map octave_swig_ref::map_value() const' virtual Octave_map map_value() const ^ In file included from /usr/include/octave-3.8.0/octave/ov.h:58:0, from /usr/include/octave-3.8.0/octave/oct-obj.h:34, from /usr/include/octave-3.8.0/octave/ov-fcn.h:32, from /usr/include/octave-3.8.0/octave/ov-builtin.h:28, from /usr/include/octave-3.8.0/octave/defun-int.h:28, from /usr/include/octave-3.8.0/octave/defun-dld.h:30, from /usr/include/octave-3.8.0/octave/oct.h:36, from /builddir/build/BUILD/plplot-5.9.11/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:154: /usr/include/octave-3.8.0/octave/ov-base.h:568:22: error: overriding 'virtual octave_map octave_base_value::map_value() const' virtual octave_map map_value (void) const; ^ /builddir/build/BUILD/plplot-5.9.11/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx: In function 'void SWIG_Octave_LinkGlobalValue(std::string)': /builddir/build/BUILD/plplot-5.9.11/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:2052:28: warning: 'static octave_value& symbol_table::varref(const string&, symbol_table::scope_id, symbol_table::context_id, bool)' is deprecated (declared at /usr/include/octave-3.8.0/octave/symtab.h:1322) [-Wdeprecated-declarations] symbol_table::varref(name); ^ /builddir/build/BUILD/plplot-5.9.11/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx: In function 'void labelfunc_octave(PLINT, PLFLT, char*, PLINT, PLPointer)': /builddir/build/BUILD/plplot-5.9.11/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:2310:13: warning: unused variable 'i' [-Wunused-variable] int i; ^ /builddir/build/BUILD/plplot-5.9.11/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx: In function 'void ct_octave(PLFLT, PLFLT, PLFLT*, PLFLT*, PLPointer)': /builddir/build/BUILD/plplot-5.9.11/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:2336:27: warning: unused variable 'i' [-Wunused-variable] octave_idx_type i; ^ /builddir/build/BUILD/plplot-5.9.11/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx: In function 'octave_value_list _wrap_plGetCursor(const octave_value_list&, int)': /builddir/build/BUILD/plplot-5.9.11/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:8412:60: warning: 'octave_value::octave_value(const charMatrix&, bool, char)' is deprecated (declared at /usr/include/octave-3.8.0/octave/ov.h:242) [-Wdeprecated-declarations] retval4( 0 ) = octave_value( charMatrix( 80, 1 ), true ); ^ /builddir/build/BUILD/plplot-5.9.11/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx: In function 'octave_value_list _wrap_plgdev(const octave_value_list&, int)': /builddir/build/BUILD/plplot-5.9.11/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:15264:60: warning: 'octave_value::octave_value(const charMatrix&, bool, char)' is deprecated (declared at /usr/include/octave-3.8.0/octave/ov.h:242) [-Wdeprecated-declarations] retval1( 0 ) = octave_value( charMatrix( 80, 1 ), true ); ^ /builddir/build/BUILD/plplot-5.9.11/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx: In function 'octave_value_list _wrap_plgfnam(const octave_value_list&, int)': /builddir/build/BUILD/plplot-5.9.11/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:15510:60: warning: 'octave_value::octave_value(const charMatrix&, bool, char)' is deprecated (declared at /usr/include/octave-3.8.0/octave/ov.h:242) [-Wdeprecated-declarations] retval1( 0 ) = octave_value( charMatrix( 80, 1 ), true ); ^ /builddir/build/BUILD/plplot-5.9.11/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx: In function 'octave_value_list _wrap_plgver(const octave_value_list&, int)': /builddir/build/BUILD/plplot-5.9.11/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:15793:60: warning: 'octave_value::octave_value(const charMatrix&, bool, char)' is deprecated (declared at /usr/include/octave-3.8.0/octave/ov.h:242) [-Wdeprecated-declarations] retval1( 0 ) = octave_value( charMatrix( 80, 1 ), true ); ^ /builddir/build/BUILD/plplot-5.9.11/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx: In function 'bool SWIG_Octave_LoadModule(std::string)': /builddir/build/BUILD/plplot-5.9.11/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:21858:5: error: 'begin_frame' is not a member of 'unwind_protect' unwind_protect::begin_frame("SWIG_Octave_LoadModule"); ^ /builddir/build/BUILD/plplot-5.9.11/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:21859:35: error: 'unwind_protect_int' was not declared in this scope unwind_protect_int(error_state); ^ /builddir/build/BUILD/plplot-5.9.11/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:21861:47: error: 'unwind_protect_bool' was not declared in this scope unwind_protect_bool(discard_error_messages); ^ /builddir/build/BUILD/plplot-5.9.11/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:21877:5: error: 'run_frame' is not a member of 'unwind_protect' unwind_protect::run_frame("SWIG_Octave_LoadModule"); ^ /builddir/build/BUILD/plplot-5.9.11/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx: In function 'bool SWIG_Octave_InstallFunction(octave_function*, std::string)': /builddir/build/BUILD/plplot-5.9.11/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:21890:5: error: 'begin_frame' is not a member of 'unwind_protect' unwind_protect::begin_frame("SWIG_Octave_InstallFunction"); ^ /builddir/build/BUILD/plplot-5.9.11/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:21891:35: error: 'unwind_protect_int' was not declared in this scope unwind_protect_int(error_state); ^ /builddir/build/BUILD/plplot-5.9.11/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:21893:47: error: 'unwind_protect_bool' was not declared in this scope unwind_protect_bool(discard_error_messages); ^ /builddir/build/BUILD/plplot-5.9.11/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:21913:5: error: 'run_frame' is not a member of 'unwind_protect' unwind_protect::run_frame("SWIG_Octave_InstallFunction"); ^ /builddir/build/BUILD/plplot-5.9.11/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx: In member function 'virtual dim_vector octave_swig_type::dims() const': /builddir/build/BUILD/plplot-5.9.11/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:1200:5: warning: control reaches end of non-void function [-Wreturn-type] } ^ /builddir/build/BUILD/plplot-5.9.11/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx: At global scope: /builddir/build/BUILD/plplot-5.9.11/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:1859:28: warning: 'octave_value_list octave_set_immutable(const octave_value_list&, int)' defined but not used [-Wunused-function] static octave_value_list octave_set_immutable(const octave_value_list &args, int nargout) { ^ /builddir/build/BUILD/plplot-5.9.11/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:2158:5: warning: 'int _arraylen(const octave_value&)' defined but not used [-Wunused-function] _arraylen( const octave_value &o_obj ) ^ -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane or...@co... Boulder, CO 80301 http://www.cora.nwra.com |
From: Orion P. <or...@co...> - 2013-12-30 03:40:08
|
On 12/29/2013 08:25 PM, Orion Poplawski wrote: > On 12/29/2013 01:34 PM, Alan W. Irwin wrote: >> Please let me know if my latest PLplot change from config.h to >> plplot_config.h (revision 12914) solves this issue. Of course, if it >> doesn't solve it, the change was worth doing anyway. And if it does >> solve it, I hope your bug report still convinces the Octave developers >> to move back to using the quoted form of #include for config.h (or >> better yet change the name to octave_config.h). After all, there are >> likely quite a few software projects still left out there that do use >> the config.h name (at least internally in their build tree as PLplot >> did up to now). >> >> Alan > > > Alan - That does indeed get us further - but now we seem to be into the > meat of the API changes in octave: > > /usr/bin/cmake -E cmake_progress_report > /builddir/build/BUILD/plplot-5.9.11/fedora/CMakeFiles 19 > [ 13%] Building CXX object > bindings/octave/CMakeFiles/plplot_octave.dir/plplot_octaveOCTAVE_wrap.cxx.o > cd /builddir/build/BUILD/plplot-5.9.11/fedora/bindings/octave && > /usr/bin/c++ -DHAVE_CONFIG_H -Dplplot_octave_EXPORTS -O2 -g -pipe > -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions > -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches > -m32 -march=i686 -mtune=atom -fasynchronous-unwind-tables -fPIC > -I/builddir/build/BUILD/plplot-5.9.11/include > -I/builddir/build/BUILD/plplot-5.9.11/lib/qsastime > -I/builddir/build/BUILD/plplot-5.9.11/fedora > -I/builddir/build/BUILD/plplot-5.9.11/fedora/include > -I/builddir/build/BUILD/plplot-5.9.11/fedora/bindings/octave > -I/usr/include/octave-3.8.0 -I/usr/include/octave-3.8.0/octave > -I/builddir/build/BUILD/plplot-5.9.11/bindings/swig-support -o > CMakeFiles/plplot_octave.dir/plplot_octaveOCTAVE_wrap.cxx.o -c > /builddir/build/BUILD/plplot-5.9.11/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx > /builddir/build/BUILD/plplot-5.9.11/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:1507:36: > warning: 'Octave_map' is deprecated (declared at > /usr/include/octave-3.8.0/octave/oct-map.h:484) [-Wdeprecated-declarations] > virtual Octave_map map_value() const { > ^ > /builddir/build/BUILD/plplot-5.9.11/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:1507:24: > error: invalid covariant return type for 'virtual Octave_map > octave_swig_type::map_value() const' > virtual Octave_map map_value() const { > ^ So much/most of this may be a swig issue. I filed https://sourceforge.net/p/swig/bugs/1353/ for it. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane or...@co... Boulder, CO 80301 http://www.cora.nwra.com |
From: Alan W. I. <ir...@be...> - 2013-12-30 20:08:42
|
On 2013-12-29 20:39-0700 Orion Poplawski wrote: > On 12/29/2013 08:25 PM, Orion Poplawski wrote: >> On 12/29/2013 01:34 PM, Alan W. Irwin wrote: >>> Please let me know if my latest PLplot change from config.h to >>> plplot_config.h (revision 12914) solves this issue. Of course, if it >>> doesn't solve it, the change was worth doing anyway. And if it does >>> solve it, I hope your bug report still convinces the Octave developers >>> to move back to using the quoted form of #include for config.h (or >>> better yet change the name to octave_config.h). After all, there are >>> likely quite a few software projects still left out there that do use >>> the config.h name (at least internally in their build tree as PLplot >>> did up to now). >>> >>> Alan >> >> >> Alan - That does indeed get us further - but now we seem to be into the >> meat of the API changes in octave: >> >> /usr/bin/cmake -E cmake_progress_report >> /builddir/build/BUILD/plplot-5.9.11/fedora/CMakeFiles 19 >> [ 13%] Building CXX object >> bindings/octave/CMakeFiles/plplot_octave.dir/plplot_octaveOCTAVE_wrap.cxx.o >> cd /builddir/build/BUILD/plplot-5.9.11/fedora/bindings/octave && >> /usr/bin/c++ -DHAVE_CONFIG_H -Dplplot_octave_EXPORTS -O2 -g -pipe >> -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions >> -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches >> -m32 -march=i686 -mtune=atom -fasynchronous-unwind-tables -fPIC >> -I/builddir/build/BUILD/plplot-5.9.11/include >> -I/builddir/build/BUILD/plplot-5.9.11/lib/qsastime >> -I/builddir/build/BUILD/plplot-5.9.11/fedora >> -I/builddir/build/BUILD/plplot-5.9.11/fedora/include >> -I/builddir/build/BUILD/plplot-5.9.11/fedora/bindings/octave >> -I/usr/include/octave-3.8.0 -I/usr/include/octave-3.8.0/octave >> -I/builddir/build/BUILD/plplot-5.9.11/bindings/swig-support -o >> CMakeFiles/plplot_octave.dir/plplot_octaveOCTAVE_wrap.cxx.o -c >> /builddir/build/BUILD/plplot-5.9.11/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx >> /builddir/build/BUILD/plplot-5.9.11/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:1507:36: >> warning: 'Octave_map' is deprecated (declared at >> /usr/include/octave-3.8.0/octave/oct-map.h:484) [-Wdeprecated-declarations] >> virtual Octave_map map_value() const { >> ^ >> /builddir/build/BUILD/plplot-5.9.11/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:1507:24: >> error: invalid covariant return type for 'virtual Octave_map >> octave_swig_type::map_value() const' >> virtual Octave_map map_value() const { >> ^ > > So much/most of this may be a swig issue. I filed > https://sourceforge.net/p/swig/bugs/1353/ for it. Looking further, I think this issue is very likely an Octave one. For example, the above virtual command occurs in the following context in my version of the generated /bindings/octave/plplot_octaveOCTAVE_wrap.cxx #if OCTAVE_API_VERSION_NUMBER >= 40 virtual octave_map map_value() const { return octave_map(); } #else virtual Octave_map map_value() const { return Octave_map(); } #endif As you appear to be already aware, this is C++ code generated by swig and not by any of our typemaps in bindings/octave/plplot_octaveOCTAVE_wrap.cxx so your first reaction that it is a swig issue is understandable. But note above that the capitalized version which causes the issue above, i.e., virtual Octave_map map_value() const { is meant to be used only for very old octave versions. For example, I get the following result on my system: irwin@raven> find /usr/include/octave-* -type f |xargs grep \ OCTAVE_API_VERSION_NUMBER /usr/include/octave-3.6.2/octave/version.h:#define OCTAVE_API_VERSION_NUMBER 48 Please try the same command on Fedora. I am pretty sure you will find that the issue is that octave-3.8.0 has failed to define OCTAVE_API_VERSION_NUMBER at all (or else used an incorrect low number) which would be a serious octave-3.8.0 bug. Note my incoming e-mail has been disrupted again today by my University service provider so if you or Andrew have already come to similar conclusions, I haven't had a chance to see them yet. 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...> - 2013-12-30 20:19:58
|
On 2013-12-30 12:08-0800 Alan W. Irwin wrote: > Note my incoming e-mail has been disrupted again today by my > University service provider so if you or Andrew have already come to > similar conclusions, I haven't had a chance to see them yet. P.S. Actually, I jumped to a premature conclusion above based on my previous bad e-mail experience during this Christmas break. It turned out the particular astrogroup computer I was using to retrieve my e-mail from the university has indeed gone down, but there are several other alternative astrogroup computers I can use to retrieve my e-mail, and they are working fine today (so far at least). 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: Orion P. <or...@co...> - 2013-12-30 20:42:46
|
On 12/30/2013 01:08 PM, Alan W. Irwin wrote: > On 2013-12-29 20:39-0700 Orion Poplawski wrote: > >> On 12/29/2013 08:25 PM, Orion Poplawski wrote: >>> On 12/29/2013 01:34 PM, Alan W. Irwin wrote: >>>> Please let me know if my latest PLplot change from config.h to >>>> plplot_config.h (revision 12914) solves this issue. Of course, if it >>>> doesn't solve it, the change was worth doing anyway. And if it does >>>> solve it, I hope your bug report still convinces the Octave developers >>>> to move back to using the quoted form of #include for config.h (or >>>> better yet change the name to octave_config.h). After all, there are >>>> likely quite a few software projects still left out there that do use >>>> the config.h name (at least internally in their build tree as PLplot >>>> did up to now). >>>> >>>> Alan >>> >>> >>> Alan - That does indeed get us further - but now we seem to be into the >>> meat of the API changes in octave: >>> >>> /usr/bin/cmake -E cmake_progress_report >>> /builddir/build/BUILD/plplot-5.9.11/fedora/CMakeFiles 19 >>> [ 13%] Building CXX object >>> bindings/octave/CMakeFiles/plplot_octave.dir/plplot_octaveOCTAVE_wrap.cxx.o >>> cd /builddir/build/BUILD/plplot-5.9.11/fedora/bindings/octave && >>> /usr/bin/c++ -DHAVE_CONFIG_H -Dplplot_octave_EXPORTS -O2 -g -pipe >>> -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions >>> -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches >>> -m32 -march=i686 -mtune=atom -fasynchronous-unwind-tables -fPIC >>> -I/builddir/build/BUILD/plplot-5.9.11/include >>> -I/builddir/build/BUILD/plplot-5.9.11/lib/qsastime >>> -I/builddir/build/BUILD/plplot-5.9.11/fedora >>> -I/builddir/build/BUILD/plplot-5.9.11/fedora/include >>> -I/builddir/build/BUILD/plplot-5.9.11/fedora/bindings/octave >>> -I/usr/include/octave-3.8.0 -I/usr/include/octave-3.8.0/octave >>> -I/builddir/build/BUILD/plplot-5.9.11/bindings/swig-support -o >>> CMakeFiles/plplot_octave.dir/plplot_octaveOCTAVE_wrap.cxx.o -c >>> /builddir/build/BUILD/plplot-5.9.11/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx >>> >>> /builddir/build/BUILD/plplot-5.9.11/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:1507:36: >>> >>> warning: 'Octave_map' is deprecated (declared at >>> /usr/include/octave-3.8.0/octave/oct-map.h:484) [-Wdeprecated-declarations] >>> virtual Octave_map map_value() const { >>> ^ >>> /builddir/build/BUILD/plplot-5.9.11/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:1507:24: >>> >>> error: invalid covariant return type for 'virtual Octave_map >>> octave_swig_type::map_value() const' >>> virtual Octave_map map_value() const { >>> ^ >> >> So much/most of this may be a swig issue. I filed >> https://sourceforge.net/p/swig/bugs/1353/ for it. > > Looking further, I think this issue is very likely an Octave one. For > example, the above virtual command occurs in the following context > in my version of the generated > /bindings/octave/plplot_octaveOCTAVE_wrap.cxx > > #if OCTAVE_API_VERSION_NUMBER >= 40 > virtual octave_map map_value() const { > return octave_map(); > } > #else > virtual Octave_map map_value() const { > return Octave_map(); > } > #endif > > As you appear to be already aware, this is C++ code generated by swig and not > by any of our > typemaps in bindings/octave/plplot_octaveOCTAVE_wrap.cxx so your first > reaction that it is a swig issue is understandable. But note above > that the capitalized version which causes the issue above, i.e., > > virtual Octave_map map_value() const { > > is meant to be used only for very old octave versions. For example, > I get the following result on my system: > > irwin@raven> find /usr/include/octave-* -type f |xargs grep \ > OCTAVE_API_VERSION_NUMBER > > /usr/include/octave-3.6.2/octave/version.h:#define OCTAVE_API_VERSION_NUMBER 48 > > Please try the same command on Fedora. I am pretty sure you will find > that the issue is that octave-3.8.0 has failed to define > OCTAVE_API_VERSION_NUMBER at all (or else used an incorrect low number) > which would be a serious octave-3.8.0 bug. > > Alan Ah, you hit the nail on the head - they dropped OCTAVE_API_VERSION_NUMBER completely. I've sent an email to the octave developers asking why. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nw... Boulder, CO 80301 http://www.nwra.com |
From: Alan W. I. <ir...@be...> - 2013-12-31 18:57:03
|
On 2013-12-30 13:42-0700 Orion Poplawski wrote: > Ah, you hit the nail on the head - they dropped OCTAVE_API_VERSION_NUMBER > completely. I've sent an email to the octave developers asking why. To see if there are any more octave-3.8.0 issues beyond this one, I suggest you temporarily add #define OCTAVE_API_VERSION_NUMBER 49 to the generated bindings/octave/plplot_octaveOCTAVE_wrap.cxx file and see how far you get with # Test of the bindings and examples for all our supported languages # including Octave. (This only tests our low-level Octave bindings.) make test_noninteractive If that works and gives no PostScript differences between the octave and C results, then as an experiment you might also want to try # Experimental test of our high-level, interactive octave API (for xwin device) make test_octave_xwin The first of those tests works well on my octave-3.6.2 platform and Andrew's octave-3.6.4 platforms. The second of those tests works reasonably well on my platform (i.e., some minor rendering issues but no obvious run-time issues) with some very pretty interactive effects such as the plot where you can view a 3D plot from all altitudes/azimuths using mouse drag and drop. However, previous experience found some severe run-time issues with this target on other Linux platforms than mine (I think Andrew found those). It was not clear whether the issues were due to Octave bugs or something wrong with our high-level Octave bindings. But I suggest the test above just in case the first explanation is the correct one, and those bugs have now been fixed in all modern Octave versions. 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: Orion P. <or...@co...> - 2013-12-31 23:53:09
|
On 12/31/2013 11:56 AM, Alan W. Irwin wrote: > On 2013-12-30 13:42-0700 Orion Poplawski wrote: > >> Ah, you hit the nail on the head - they dropped OCTAVE_API_VERSION_NUMBER >> completely. I've sent an email to the octave developers asking why. > > To see if there are any more octave-3.8.0 issues beyond this one, I > suggest you temporarily add > > #define OCTAVE_API_VERSION_NUMBER 49 > > to the generated bindings/octave/plplot_octaveOCTAVE_wrap.cxx > file and see how far you get with cd /home/orion/fedora/plplot/plplot-5.9.11/fedora/bindings/octave && /usr/lib64/ccache/c++ -DHAVE_CONFIG_H -Dplplot_octave_EXPORTS -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -fPIC -I/home/orion/fedora/plplot/plplot-5.9.11/include -I/home/orion/fedora/plplot/plplot-5.9.11/lib/qsastime -I/home/orion/fedora/plplot/plplot-5.9.11/fedora -I/home/orion/fedora/plplot/plplot-5.9.11/fedora/include -I/home/orion/fedora/plplot/plplot-5.9.11/fedora/bindings/octave -I/usr/include/octave-3.8.0 -I/usr/include/octave-3.8.0/octave -I/home/orion/fedora/plplot/plplot-5.9.11/bindings/swig-support -o CMakeFiles/plplot_octave.dir/plplot_octaveOCTAVE_wrap.cxx.o -c /home/orion/fedora/plplot/plplot-5.9.11/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx /home/orion/fedora/plplot/plplot-5.9.11/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx: In member function ‘virtual dim_vector octave_swig_type::dims() const’: /home/orion/fedora/plplot/plplot-5.9.11/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:1183:46: error: ‘class octave_value’ has no member named ‘is_real_nd_array’ } else if (out.is_matrix_type() || out.is_real_nd_array() || out.is_numeric_type() ) { ^ /home/orion/fedora/plplot/plplot-5.9.11/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx: In function ‘void SWIG_Octave_LinkGlobalValue(std::string)’: /home/orion/fedora/plplot/plplot-5.9.11/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:2052:28: warning: ‘static octave_value& symbol_table::varref(const string&, symbol_table::scope_id, symbol_table::context_id, bool)’ is deprecated (declared at /usr/include/octave-3.8.0/octave/symtab.h:1322) [-Wdeprecated-declarations] symbol_table::varref(name); ^ /home/orion/fedora/plplot/plplot-5.9.11/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx: In function ‘void labelfunc_octave(PLINT, PLFLT, char*, PLINT, PLPointer)’: /home/orion/fedora/plplot/plplot-5.9.11/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:2310:13: warning: unused variable ‘i’ [-Wunused-variable] int i; ^ /home/orion/fedora/plplot/plplot-5.9.11/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx: In function ‘void ct_octave(PLFLT, PLFLT, PLFLT*, PLFLT*, PLPointer)’: /home/orion/fedora/plplot/plplot-5.9.11/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:2336:25: warning: unused variable ‘i’ [-Wunused-variable] octave_idx_type i; ^ /home/orion/fedora/plplot/plplot-5.9.11/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx: In member function ‘virtual dim_vector octave_swig_type::dims() const’: /home/orion/fedora/plplot/plplot-5.9.11/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:1200:5: warning: control reaches end of non-void function [-Wreturn-type] } ^ /home/orion/fedora/plplot/plplot-5.9.11/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx: At global scope: /home/orion/fedora/plplot/plplot-5.9.11/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:1859:28: warning: ‘octave_value_list octave_set_immutable(const octave_value_list&, int)’ defined but not used [-Wunused-function] static octave_value_list octave_set_immutable(const octave_value_list &args, int nargout) { ^ /home/orion/fedora/plplot/plplot-5.9.11/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:2158:5: warning: ‘int _arraylen(const octave_value&)’ defined but not used [-Wunused-function] _arraylen( const octave_value &o_obj ) ^ make[2]: *** [bindings/octave/CMakeFiles/plplot_octave.dir/plplot_octaveOCTAVE_wrap.cxx.o] Error 1 -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nw... Boulder, CO 80301 http://www.nwra.com |
From: Alan W. I. <ir...@be...> - 2014-01-01 01:50:21
|
Hi Orion: Thanks for doing that suggested experiment. More below in context. On 2013-12-31 16:52-0700 Orion Poplawski wrote: > On 12/31/2013 11:56 AM, Alan W. Irwin wrote: >> On 2013-12-30 13:42-0700 Orion Poplawski wrote: >> >>> Ah, you hit the nail on the head - they dropped OCTAVE_API_VERSION_NUMBER >>> completely. I've sent an email to the octave developers asking why. >> >> To see if there are any more octave-3.8.0 issues beyond this one, I >> suggest you temporarily add >> >> #define OCTAVE_API_VERSION_NUMBER 49 >> >> to the generated bindings/octave/plplot_octaveOCTAVE_wrap.cxx >> file and see how far you get with > > cd /home/orion/fedora/plplot/plplot-5.9.11/fedora/bindings/octave && > /usr/lib64/ccache/c++ -DHAVE_CONFIG_H -Dplplot_octave_EXPORTS -O2 -g -pipe > -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions > -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 > -mtune=generic -fPIC -I/home/orion/fedora/plplot/plplot-5.9.11/include > -I/home/orion/fedora/plplot/plplot-5.9.11/lib/qsastime > -I/home/orion/fedora/plplot/plplot-5.9.11/fedora > -I/home/orion/fedora/plplot/plplot-5.9.11/fedora/include > -I/home/orion/fedora/plplot/plplot-5.9.11/fedora/bindings/octave > -I/usr/include/octave-3.8.0 -I/usr/include/octave-3.8.0/octave > -I/home/orion/fedora/plplot/plplot-5.9.11/bindings/swig-support -o > CMakeFiles/plplot_octave.dir/plplot_octaveOCTAVE_wrap.cxx.o -c > /home/orion/fedora/plplot/plplot-5.9.11/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx > /home/orion/fedora/plplot/plplot-5.9.11/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx: > In member function ‘virtual dim_vector octave_swig_type::dims() const’: > /home/orion/fedora/plplot/plplot-5.9.11/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:1183:46: > error: ‘class octave_value’ has no member named ‘is_real_nd_array’ > } else if (out.is_matrix_type() || out.is_real_nd_array() || > out.is_numeric_type() ) { > ^ "is_real_nd_array" is only used in a function that is provided by swig (as opposed to C++ interface code supplied by PLplot). So I would summarize this issue as a backwards-incompatible Octave change (or bug) that is confounding swig very similar to the missing OCTAVE_API_VERSION_NUMBER #define. Again, I think the Octave developers should be consulted about this to see whether this is a bug or an intended backwards-incompatible change in the Octave C++ library API. I won't comment on the rest of the compiler messages you listed since they all appear to be compiler warning messages as opposed to the much more serious compiler error message above that breaks our build. I have finally found the release notes for octave-3.8.0 at <http://www.gnu.org/software/octave/NEWS-3.8.html> which list some of the new features and backwards incompatible changes. I think most/all of those are relevant only for octave source code and not for the octave C++ library. Nevertheless I mention that URL because that document may be a good guide to any changes we may have to make in our octave-level source code if/when we find a way to get the swig-generated octave bindings built for Octave version 3.8.x. 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: Orion P. <or...@co...> - 2014-01-03 22:07:45
|
On 12/31/2013 06:50 PM, Alan W. Irwin wrote: > Hi Orion: > > Thanks for doing that suggested experiment. More below > in context. > > On 2013-12-31 16:52-0700 Orion Poplawski wrote: > >> On 12/31/2013 11:56 AM, Alan W. Irwin wrote: >>> On 2013-12-30 13:42-0700 Orion Poplawski wrote: >>> >>>> Ah, you hit the nail on the head - they dropped OCTAVE_API_VERSION_NUMBER >>>> completely. I've sent an email to the octave developers asking why. >>> >>> To see if there are any more octave-3.8.0 issues beyond this one, I >>> suggest you temporarily add >>> >>> #define OCTAVE_API_VERSION_NUMBER 49 >>> >>> to the generated bindings/octave/plplot_octaveOCTAVE_wrap.cxx >>> file and see how far you get with >> >> cd /home/orion/fedora/plplot/plplot-5.9.11/fedora/bindings/octave && >> /usr/lib64/ccache/c++ -DHAVE_CONFIG_H -Dplplot_octave_EXPORTS -O2 -g -pipe >> -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions >> -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 >> -mtune=generic -fPIC -I/home/orion/fedora/plplot/plplot-5.9.11/include >> -I/home/orion/fedora/plplot/plplot-5.9.11/lib/qsastime >> -I/home/orion/fedora/plplot/plplot-5.9.11/fedora >> -I/home/orion/fedora/plplot/plplot-5.9.11/fedora/include >> -I/home/orion/fedora/plplot/plplot-5.9.11/fedora/bindings/octave >> -I/usr/include/octave-3.8.0 -I/usr/include/octave-3.8.0/octave >> -I/home/orion/fedora/plplot/plplot-5.9.11/bindings/swig-support -o >> CMakeFiles/plplot_octave.dir/plplot_octaveOCTAVE_wrap.cxx.o -c >> /home/orion/fedora/plplot/plplot-5.9.11/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx >> >> /home/orion/fedora/plplot/plplot-5.9.11/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx: >> >> In member function ‘virtual dim_vector octave_swig_type::dims() const’: >> /home/orion/fedora/plplot/plplot-5.9.11/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:1183:46: >> >> error: ‘class octave_value’ has no member named ‘is_real_nd_array’ >> } else if (out.is_matrix_type() || out.is_real_nd_array() || >> out.is_numeric_type() ) { >> ^ > > "is_real_nd_array" is only used in a function that is provided by swig > (as opposed to C++ interface code supplied by PLplot). So I would > summarize this issue as a backwards-incompatible Octave change (or > bug) that is confounding swig very similar to the missing > OCTAVE_API_VERSION_NUMBER #define. > > Again, I think the Octave developers should be consulted about this to > see whether this is a bug or an intended backwards-incompatible change > in the Octave C++ library API. According to the octave folks, "is_real_nd_array()" was intentionally removed, and may indeed have only ever returned "false". octave upstream seems adverse to re-adding OCTAVE_API_VERSION_NUMBER. I have gotten no response yet to my swig bug: https://sourceforge.net/p/swig/bugs/1353/ I may be able to put some hacks into the Fedora swig package to work around these problems, but I rather avoid it. Any suggestions for how to proceed? Have you had any luck with the swig folks? -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nw... Boulder, CO 80301 http://www.nwra.com |
From: Alan W. I. <ir...@be...> - 2014-01-04 00:59:55
|
On 2014-01-03 15:07-0700 Orion Poplawski wrote: > On 12/31/2013 06:50 PM, Alan W. Irwin wrote: >> Hi Orion: >> >> Thanks for doing that suggested experiment. More below >> in context. >> >> On 2013-12-31 16:52-0700 Orion Poplawski wrote: >> >>> On 12/31/2013 11:56 AM, Alan W. Irwin wrote: >>>> On 2013-12-30 13:42-0700 Orion Poplawski wrote: >>>> >>>>> Ah, you hit the nail on the head - they dropped OCTAVE_API_VERSION_NUMBER >>>>> completely. I've sent an email to the octave developers asking why. >>>> >>>> To see if there are any more octave-3.8.0 issues beyond this one, I >>>> suggest you temporarily add >>>> >>>> #define OCTAVE_API_VERSION_NUMBER 49 >>>> >>>> to the generated bindings/octave/plplot_octaveOCTAVE_wrap.cxx >>>> file and see how far you get with >>> >>> cd /home/orion/fedora/plplot/plplot-5.9.11/fedora/bindings/octave && >>> /usr/lib64/ccache/c++ -DHAVE_CONFIG_H -Dplplot_octave_EXPORTS -O2 -g -pipe >>> -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions >>> -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 >>> -mtune=generic -fPIC -I/home/orion/fedora/plplot/plplot-5.9.11/include >>> -I/home/orion/fedora/plplot/plplot-5.9.11/lib/qsastime >>> -I/home/orion/fedora/plplot/plplot-5.9.11/fedora >>> -I/home/orion/fedora/plplot/plplot-5.9.11/fedora/include >>> -I/home/orion/fedora/plplot/plplot-5.9.11/fedora/bindings/octave >>> -I/usr/include/octave-3.8.0 -I/usr/include/octave-3.8.0/octave >>> -I/home/orion/fedora/plplot/plplot-5.9.11/bindings/swig-support -o >>> CMakeFiles/plplot_octave.dir/plplot_octaveOCTAVE_wrap.cxx.o -c >>> /home/orion/fedora/plplot/plplot-5.9.11/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx >>> >>> /home/orion/fedora/plplot/plplot-5.9.11/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx: >>> >>> In member function ‘virtual dim_vector octave_swig_type::dims() const’: >>> /home/orion/fedora/plplot/plplot-5.9.11/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:1183:46: >>> >>> error: ‘class octave_value’ has no member named ‘is_real_nd_array’ >>> } else if (out.is_matrix_type() || out.is_real_nd_array() || >>> out.is_numeric_type() ) { >>> ^ >> >> "is_real_nd_array" is only used in a function that is provided by swig >> (as opposed to C++ interface code supplied by PLplot). So I would >> summarize this issue as a backwards-incompatible Octave change (or >> bug) that is confounding swig very similar to the missing >> OCTAVE_API_VERSION_NUMBER #define. >> >> Again, I think the Octave developers should be consulted about this to >> see whether this is a bug or an intended backwards-incompatible change >> in the Octave C++ library API. > > According to the octave folks, "is_real_nd_array()" was intentionally removed, > and may indeed have only ever returned "false". > > octave upstream seems adverse to re-adding OCTAVE_API_VERSION_NUMBER. > > I have gotten no response yet to my swig bug: > https://sourceforge.net/p/swig/bugs/1353/ > I found via google the octave threads at http://octave.1599824.n4.nabble.com/Why-no-more-OCTAVE-API-VERSION-NUMBER-td4660468.html and http://octave.1599824.n4.nabble.com/Any-documentation-of-changes-to-libinterp-API-td4660492.html where octave developers replied to your two reports, and I agree with your conclusion that it looks like they will do nothing to rescind those backwards incompatibilities. > [out of order]I may be able to put some hacks into the Fedora swig package to work around > these problems, but I rather avoid it. > > Any suggestions for how to proceed? For the PLplot build system it should be straightforward to create an Octave version test. Also, I am pretty sure that swig users are allowed to redefine any core swig functionality. Thus, for any Octave version greater than 3.6.4, we would want to #define OCTAVE-API-VERSION-NUMBER and simply copy the the swig core functionality that currently uses is_real_nd_array() and modify it to drop that call. But I don't understand OOP well enough to figure out the code unit that needs to be copied so I hope you or Andrew can figure that out (or figure out some other simpler means of effectively dropping that call to is_real_nd_array()). > Have you had any luck with the swig folks? I haven't tried yet since I think your bug report will need to be supplemented if we attempt to follow the above plan to modify PLplot so it will work properly with Octave-3.8.0. Once 3.8.0 works for us, you should update that bug report with a patch to swig that takes all measures we discover need to be made in the PLplot case. At that point I would be willing to bring up your bug report on the swig mailing list. There is nothing like a patch (no matter how crude/brute force) to focus and attract discussion. 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: Orion P. <or...@co...> - 2014-01-07 03:38:17
|
On 01/03/2014 05:59 PM, Alan W. Irwin wrote: > On 2014-01-03 15:07-0700 Orion Poplawski wrote: > >> On 12/31/2013 06:50 PM, Alan W. Irwin wrote: >>> Hi Orion: >>> >>> Thanks for doing that suggested experiment. More below >>> in context. >>> >>> On 2013-12-31 16:52-0700 Orion Poplawski wrote: >>> >>>> On 12/31/2013 11:56 AM, Alan W. Irwin wrote: >>>>> On 2013-12-30 13:42-0700 Orion Poplawski wrote: >>>>> >>>>>> Ah, you hit the nail on the head - they dropped >>>>>> OCTAVE_API_VERSION_NUMBER >>>>>> completely. I've sent an email to the octave developers asking why. >>>>> >>>>> To see if there are any more octave-3.8.0 issues beyond this one, I >>>>> suggest you temporarily add >>>>> >>>>> #define OCTAVE_API_VERSION_NUMBER 49 >>>>> >>>>> to the generated bindings/octave/plplot_octaveOCTAVE_wrap.cxx >>>>> file and see how far you get with >>>> >>>> cd /home/orion/fedora/plplot/plplot-5.9.11/fedora/bindings/octave && >>>> /usr/lib64/ccache/c++ -DHAVE_CONFIG_H -Dplplot_octave_EXPORTS -O2 >>>> -g -pipe >>>> -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions >>>> -fstack-protector-strong --param=ssp-buffer-size=4 >>>> -grecord-gcc-switches -m64 >>>> -mtune=generic -fPIC -I/home/orion/fedora/plplot/plplot-5.9.11/include >>>> -I/home/orion/fedora/plplot/plplot-5.9.11/lib/qsastime >>>> -I/home/orion/fedora/plplot/plplot-5.9.11/fedora >>>> -I/home/orion/fedora/plplot/plplot-5.9.11/fedora/include >>>> -I/home/orion/fedora/plplot/plplot-5.9.11/fedora/bindings/octave >>>> -I/usr/include/octave-3.8.0 -I/usr/include/octave-3.8.0/octave >>>> -I/home/orion/fedora/plplot/plplot-5.9.11/bindings/swig-support -o >>>> CMakeFiles/plplot_octave.dir/plplot_octaveOCTAVE_wrap.cxx.o -c >>>> /home/orion/fedora/plplot/plplot-5.9.11/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx >>>> >>>> >>>> /home/orion/fedora/plplot/plplot-5.9.11/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx: >>>> >>>> >>>> In member function ‘virtual dim_vector octave_swig_type::dims() const’: >>>> /home/orion/fedora/plplot/plplot-5.9.11/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:1183:46: >>>> >>>> >>>> error: ‘class octave_value’ has no member named ‘is_real_nd_array’ >>>> } else if (out.is_matrix_type() || out.is_real_nd_array() || >>>> out.is_numeric_type() ) { >>>> ^ >>> >>> "is_real_nd_array" is only used in a function that is provided by swig >>> (as opposed to C++ interface code supplied by PLplot). So I would >>> summarize this issue as a backwards-incompatible Octave change (or >>> bug) that is confounding swig very similar to the missing >>> OCTAVE_API_VERSION_NUMBER #define. >>> >>> Again, I think the Octave developers should be consulted about this to >>> see whether this is a bug or an intended backwards-incompatible change >>> in the Octave C++ library API. >> >> According to the octave folks, "is_real_nd_array()" was intentionally >> removed, >> and may indeed have only ever returned "false". >> >> octave upstream seems adverse to re-adding OCTAVE_API_VERSION_NUMBER. >> >> I have gotten no response yet to my swig bug: >> https://sourceforge.net/p/swig/bugs/1353/ >> > > I found via google the octave threads at > http://octave.1599824.n4.nabble.com/Why-no-more-OCTAVE-API-VERSION-NUMBER-td4660468.html > > and > http://octave.1599824.n4.nabble.com/Any-documentation-of-changes-to-libinterp-API-td4660492.html > > where octave developers replied to your two reports, and I agree with > your conclusion that it looks like they will do nothing to rescind > those backwards incompatibilities. > >> [out of order]I may be able to put some hacks into the Fedora swig >> package to work around >> these problems, but I rather avoid it. >> >> Any suggestions for how to proceed? > > For the PLplot build system it should be straightforward to create an > Octave version test. Also, I am pretty sure that swig users are > allowed to redefine any core swig functionality. Thus, for any Octave > version greater than 3.6.4, we would want to #define > OCTAVE-API-VERSION-NUMBER and simply copy the the swig core > functionality that currently uses is_real_nd_array() and modify it to > drop that call. But I don't understand OOP well enough to figure out > the code unit that needs to be copied so I hope you or Andrew can > figure that out (or figure out some other simpler means of effectively > dropping that call to is_real_nd_array()). > >> Have you had any luck with the swig folks? > > I haven't tried yet since I think your bug report will need to be > supplemented if we attempt to follow the above plan to modify PLplot > so it will work properly with Octave-3.8.0. Once 3.8.0 works for us, > you should update that bug report with a patch to swig that takes all > measures we discover need to be made in the PLplot case. At that point > I would be willing to bring up your bug report on the swig mailing > list. There is nothing like a patch (no matter how crude/brute force) > to focus and attract discussion. > > Alan I'm afraid I'm going to bow out of being a go between here. Hopefully the SWIG and Octave folks can work it out. As it stands it seems like SWIG may drop Octave support if there is no resolution. For the time being I'm disabling plplot Octave support in Fedora Rawhide (F21). -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane or...@co... Boulder, CO 80301 http://www.cora.nwra.com |
From: Alan W. I. <ir...@be...> - 2014-01-07 12:38:24
|
On 2014-01-06 20:38-0700 Orion Poplawski wrote: > On 01/03/2014 05:59 PM, Alan W. Irwin wrote: >> For the PLplot build system it should be straightforward to create an >> Octave version test. Also, I am pretty sure that swig users are >> allowed to redefine any core swig functionality. Thus, for any Octave >> version greater than 3.6.4, we would want to #define >> OCTAVE-API-VERSION-NUMBER and simply copy the the swig core >> functionality that currently uses is_real_nd_array() and modify it to >> drop that call. But I don't understand OOP well enough to figure out >> the code unit that needs to be copied so I hope you or Andrew can >> figure that out (or figure out some other simpler means of effectively >> dropping that call to is_real_nd_array()). >> > [...]I'm afraid I'm going to bow out of being a go between here. Hopefully > the SWIG and Octave folks can work it out. As it stands it seems like > SWIG may drop Octave support if there is no resolution. > > For the time being I'm disabling plplot Octave support in Fedora Rawhide > (F21). Hi Orion: That's fine. I very much appreciate your efforts informing the octave and swig development teams about the issue. I think swig-generated bindings for octave are important for a number of software projects beyond PLplot so hopefully cooler heads will prevail, and the two teams will work it out in the long run. Meanwhile, I think a solution like above will work for us, but I am going to have to rely on Andrew for at least the C++ OOP part of that. 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 __________________________ |