Re: [Plplot-devel] Build problems with octave

[Alan W. I. <ir...@be...>]

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
__________________________