On Mon, Jul 20, 2009 at 08:42:51PM +0100, Andrew Ross wrote: > > Alan, > > I've also done the same thing with ldd / nm. I get the same missing > symbols as you. When you run moc it generates some extra > functions in the the C++ class to deal with the qt signals / slots. The > Q_OBJECT line in the C++ classes denotes the classes that this applies > to. If you look through qt.h you will see that there are unexported > typeinfo information for _only_ those classes which contain Q_OBJECT, > even though everything else is that same (e.g. c.f. the typeinfo entries > for QtPLDriver and QTPLWidget). The other entries, those containing > metaObject or metacast are generated by moc (look in the source file). > I've tried manually adding in the required attribute information to > these files but it doesn't compile. It seems that these are being defined > elsewhere through QT macros - I imagine an expansion of the Q_OBJECT tag > - and the definitions conflict. I will need to look into this further. > I'm not quite sure why this only affects the pyqt4 bindings. Presumable > qt.cpp is not using the typeinfo information.
I've worked out one way round this. The problem was that the class definitions were being split across two files - the source file and the generated moc file. These were compiled separated which seemed to upset things. If instead of compiling the moc file separately you include it in the main source file with a #include statement then all the symbols are properly exported since the class is all compiled in a single object file from a single source. This used to be the way of doing things way back when I first used qt 7 or 8 years ago. I can see no reason not to do this. This option also avoids any ugly re-writing of the moc generated file to add in PLDLLIMPEXP macros. To implement this I've had to resort to a slightly convoluted process of writing a new header file since we don't know at cmake time what the output moc file will be - this is returned by the qt4_wrap_cpp macro at make time. I also don't think I have the dependency issues right here. My current approach would also fail if there was more than one generated moc file, although we could work round this. Alan - perhaps you can cast an eye over this? You may be able to think of a better way of doing it. This just leaves the issue of getting the right PLDLLIMPEXP macros into the sip generated code. I have added the infrastructure to define the PLDLLIMPEXP_PYQT4 macros. All that is required is to add this macro to the definition of initplplot_pyqt4 in sipplplot_pyqt4cmodule.cpp and everything works. I've done this by hand and checked that the pyqt4_example.py example works correctly. I know nothing about sip. Is it possible to do this automatically or do we need to massage the code after it has been generated? Andrew ------------------------------------------------------------------------------ Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
