On 2014-11-03 07:40-0500 Hazen Babcock wrote: > On 08/28/2014 11:54 PM, Alan W. Irwin wrote: >> >> To take up this old topic again, the above speculation turned out to be >> the issue which >> was extremely easy to fix (commits 022a53b and b6e9afe). >> >> To test this build fix for yourself, use the cmake option >> -DENABLE_smoke=ON (which I currently have defaulted to OFF for the >> build system since this smoke binding should be considered >> experimental until we install at least one run-time test, see below). >> >> Then run >> >> make VERBOSE=1 smokeplplotqt >& smokeplplotqt.out >> >> and all should be well (at least it was for me). >> >> One test I did was >> >> ldd -r bindings/qt_gui/smoke/libsmokeplplotqt.so 2>&1 |less >> >> which showed no undefined symbols. (Without commit b6e9afe there >> are such undefined symbols). >> >> Please follow up by pushing at least one example that uses this smoke >> binding of libplplotqt so we have a test that this binding actually >> works at run time. > > Hi Alan, > > Returning to this old topic. Thank you for this fix which also enables me to > also compile the smoke bindings. Unfortunately however they are "empty" in > the sense that they contain no symbols specifically related to PLplot. I was > expecting to see symbols containing QtPLDriver, QtPLWidget and QtExtWidget. > You can verify this by running: > > nm -gC libsmokeplplotqt.so > > It appears to me as though what is happening is that smoke is parsing the > include/qt.h file in an environment where PLD_qtwidget and PLD_extqt widget > are not defined. I'm not sure why this is happening since these qt devices > are getting built. As I had done in a different project, I tried to define > these in bindings/qt_gui/smoke/plplotqt.h, but now they are either being > ignored or over-written during the build. > >> more plplotqt.h > #define PLD_qtwidget > #define PLD_extqt > #include "qt.h"
This fixup should have absolutely no effect since qt.h #includes plDevs.h which overwrites the above macros. On the other hand, on my platform at least both PLD_qtwidget and PLD_extqt are #defined in plDevs.h (as expected), and that should be the case for you as well. However, if you want to double check that conclusion, the make "VERBOSE=1" result will give you the exact series of commands that produce the incorrect result. To analyze how g++ is interpreting the macros, what you need to do is repeat by hand the exact g++ build command that compiles the generated source code by cutting and pasting with the exception that you use macro debug options that are mentioned in <http://gcc.gnu.org/onlinedocs/gcc-3.4.5/gcc/Debugging-Options.html>. It's been a while since I used those, but for both the C and C++ cases, it looks like (from <http://danilogiulianelli.blogspot.ca/2013/01/how-to-inspect-expanded-c-macros-with.html> the options to be added are -E -dD. I also recall the (large but extremely helpful!) results are dumped in the file mentioned in the -o option (which is normally the object file produced, but not in this case!). Once you have convinced yourself with the above that the macros are being processed correctly by g++, then the next question is why does smokegen seem to be ignoring most of qt.h when it generates code (which I confirm below). Of course, one possibility is that smokegen has a bug in how it processes macros so that it does not follow how g++ processes them, but more likely there is something wrong with our configuration of smokegen by our build system, but more about that below. I was concerned that the -g option might be hiding the symbols from you so I ran the smokeplplotqt target as reported above. The nm results on my platform confirm the issue you have reported software@raven> nm -a --demangle bindings/qt_gui/smoke/libsmokeplplotqt.so |grep -i pl 00000000002022f8 d .got.plt 0000000000000f00 t .plt 0000000000000d08 r .rela.plt 0000000000001aa0 t __smokeplplotqt::xcall_QGlobalSpace(short, void*, Smoke::StackItem*) 0000000000202470 b __smokeplplotqt::methodMaps 0000000000202430 d __smokeplplotqt::methodNames 0000000000202492 b __smokeplplotqt::argumentList 0000000000202490 b __smokeplplotqt::inheritanceList 0000000000202494 b __smokeplplotqt::ambiguousMethodList 00000000000011a0 t __smokeplplotqt::cast(void*, short, short) 0000000000202480 b __smokeplplotqt::types 00000000002023e0 d __smokeplplotqt::classes 0000000000202462 b __smokeplplotqt::methods 0000000000202440 b completed.6092 00000000000011b0 t delete_plplotqt_Smoke 00000000000011c0 t init_plplotqt_Smoke 0000000000202450 b plplotqt_Smoke For the VERBOSE=1 case, the messages issued by the smokegen command are the following: using generator "/usr/bin/../lib/smokegen/generator_smoke.so" parsing "/home/software/plplot/HEAD/plplot.git/bindings/qt_gui/smoke/plplotqt.h" QIODevice::setTextModeEnabled: The device is not open Generating SMOKE sources... preparing SMOKE data [plplotqt] writing out smokedata.cpp [plplotqt] writing out x_*.cpp [plplotqt] Done. The above "device is not open" message seems a bit suspicious. Also, in bindings/qt_gui/smoke in the build tree smokegen generates the file generator.log which contains the following line: plplotqt.h: (3, 0): Unexpected token 'K_DCOP' : This seems a bit suspicious as well. But if none of the above helps, then the fundamental question you should ask yourself is whether you also have similar issues for the hand-crafted smoke bindings you started with. If so, then I would get those issues worked out with smokegen experts before you attempt to mimic whatever you do by hand with our build system. If not, then I suggest you look very carefully at the VERBOSE=1 results to see how our build system is deviating from what you do by hand. I hope the above response to your question is of some help to you. Please let me know the answer to my fundamental question and good luck taking it from there! 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 __________________________ ------------------------------------------------------------------------------ _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
