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...@nwra.com
Boulder, CO 80301 http://www.nwra.com
------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
