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 __________________________ ------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/plplot-devel
