Hi Alan,
I probably have time today to run the test script without -j4. The other things
I do not know. The problem with the -j option occurs in MinGW-w64/MSYS, not in
Cygwin, unless I am mistaken. But I will do this anyway, just to make sure.
(Getting the results from nm will take more of my brain power than I can spare
right now. Friday ought to be a good time though)
Regards,
Arjen
> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca]
> Sent: Wednesday, December 07, 2016 8:28 AM
> To: Arjen Markus
> Cc: PLplot development list
> Subject: plplot_pyqt4 shared object build issue
>
> On 2016-12-01 08:31-0000 Arjen Markus wrote:
>
> [...]
>
> > I am not sure about the PyQt4 component. But
> when I tried to do it via the comprehensive test script, I got compilation
> errors - see
> the attached tarball.
>
> Hi Arjen:
>
> Now that I have finally had a chance to look at your report, it appears to me
> you
> have found something release critical so suddenly time is of the essence.
> Sorry
> about that.... These things always seem to happen whenever you think you can
> relax near a release date.
> :-)
>
> The first issue is you used the default -j4 for make (and likely ctest as
> well if you
> had gotten that far). I believe you have found in the past those
> intermittently failed
> for Cygwin so from now on please automate your invocation script for
> scripts/comprehensive_test.sh to always drop the -j4 arguments (by specifying
> the
> script options --build_command make --ctest_command ctest) so this issue never
> crops up again.
>
> I doubt the -j4 option on the make command (which after all normally only
> causes
> intermittent issues) was the cause of the present issue, but you never know so
> please try the same comprehensive test run again with the above issue fixed.
> If
> that shows good results we are done.
>
> But if not, and the "undefined reference" remains, please read on and send me
> back the latest report tarball (which will be a lot more understandable
> without -j4 in
> any case) and the requested other results below which I summarize at the end.
>
> Your current report is giving me some results I don't understand, but the
> issue is
> occurring exactly where I recently changed our build system so with the
> release
> coming up I hope you can quickly reply to this post.
>
> The overview is that I can build the plplot_pyqt4 shared object here (called
> dll/plplot_pyqt4.pyd there and bindings/qt_gui/pyqt4/plplot_pyqt4.so here),
> and what
> I believe is the equivalent symbol that is undefined for your shared object
> is defined
> in my shared object according to "nm". Furthermore, the reason for this good
> result
> here is the symbol is actually defined in the object
> bindings/qt_gui/pyqt4/CMakeFiles/plplot_pyqt4.dir/plplot_pyqt4_automoc.cpp.o
> (named that both here and there) which is included by the linker here into the
> plplot_pyqt4 shared object here and also the same there.
> (This is exactly the way the new AUTOMOC procedure that generates
> plplot_pyqt4_automoc.cpp.o is supposed to work.)
>
> Note the actual command that failed (from the make.out file that was jumbled
> by
> the above -j4 option, but I have excised some things to reduce the source of
> that
> confusion) was
>
> Linking CXX shared module ../../../dll/plplot_pyqt4.pyd [...] Entering
> directory
> '/cygdrive/d/plplot-
> svn/comprehensive_test_disposeable/shared/noninteractive/build_tree'
> /usr/bin/c++.exe -shared -Wl,--enable-auto-import -o
> ../../../dll/plplot_pyqt4.pyd -
> Wl,--major-image-version,0,--minor-image-version,0
> CMakeFiles/plplot_pyqt4.dir/sipplplot_pyqt4cmodule.cpp.o
> CMakeFiles/plplot_pyqt4.dir/sipplplot_pyqt4QtExtWidget.cpp.o
> CMakeFiles/plplot_pyqt4.dir/sipplplot_pyqt4QtPLDriver.cpp.o
> CMakeFiles/plplot_pyqt4.dir/sipplplot_pyqt4QtPLWidget.cpp.o
> CMakeFiles/plplot_pyqt4.dir/plplot_pyqt4_automoc.cpp.o
> ../../../dll/libplplotqt.dll.a ../.
> ./../dll/libplplot.dll.a -lpython2.7 -lQtSvg -lQtGui -lQtCore -lltdl
> -Wl,-Bstatic -ldl -lshp -
> Wl,-Bdynamic -lfreetype ../../../dll/libcsirocsa.dll.a
> ../../../dll/libcsironn.dll.a -
> lqhull ../../../dll/libqsastime.dll.a
> [...]
> CMakeFiles/plplot_pyqt4.dir/sipplplot_pyqt4QtExtWidget.cpp.o:sipplplot_pyqt4QtExt
> Widget.cpp:(.text+0x1ed): undefined reference to
> `__imp__ZN11QtExtWidget11qt_metacallEN11QMetaObject4CallEiPPv'
> CMakeFiles/plplot_pyqt4.dir/sipplplot_pyqt4QtExtWidget.cpp.o:sipplplot_pyqt4QtExt
> Widget.cpp:(.text+0x1ed): relocation truncated to fit: R_X86_64_PC32 against
> undefined symbol
> `__imp__ZN11QtExtWidget11qt_metacallEN11QMetaObject4CallEiPPv'
> [...] + other undefined references
>
> Here are the nm results for that first undefined reference
> (__imp__ZN11QtExtWidget11qt_metacallEN11QMetaObject4CallEiPPv) in a
> similar build I did here. The mangled and demangled results here are
>
> software@raven> nm --defined-only bindings/qt_gui/pyqt4/plplot_pyqt4.so |grep
> 11QtExtWidget11qt_metacallEN11QMetaObject4CallEiPPv
> 000000000001b640 t
> _ZN11QtExtWidget11qt_metacallEN11QMetaObject4CallEiPPv
> software@raven> nm --defined-only --demangle
> bindings/qt_gui/pyqt4/plplot_pyqt4.so |grep
> 'QtExtWidget.*qt_meta.*QMetaObject'
> 000000000001b640 t QtExtWidget::qt_metacall(QMetaObject::Call, int, void**)
> 00000000000089f0 t sipQtExtWidget::qt_metacall(QMetaObject::Call, int, void**)
>
> software@raven> nm --defined-only
> bindings/qt_gui/pyqt4/CMakeFiles/plplot_pyqt4.dir/plplot_pyqt4_automoc.cpp.o
> |grep 11QtExtWidget11qt_metacallEN11QMetaObject4CallEiPPv
> 0000000000000490 T
> _ZN11QtExtWidget11qt_metacallEN11QMetaObject4CallEiPPv
>
> software@raven> nm --defined-only --demangle
> bindings/qt_gui/pyqt4/CMakeFiles/plplot_pyqt4.dir/plplot_pyqt4_automoc.cpp.o |
> grep 'QtExtWidget.*qt_metacall.*QMetaObject'
> 0000000000000490 T QtExtWidget::qt_metacall(QMetaObject::Call, int, void**)
>
> The common locations 1b640 in the first set and 490 in the second set tell you
> which demangled symbol corresponds to the mangled one.
>
> I looked for "QMetaObject::Call" in the moc-generated code that is compiled
> here
> (and there?) to create the object file plplot_pyqt4_automoc.cpp.o with the
> following
> results:
>
> software@raven> grep QMetaObject::Call
> bindings/qt_gui/pyqt4/plplot_pyqt4_automoc.dir/include/moc_qt.cpp
> void MasterHandler::qt_static_metacall(QObject *_o, QMetaObject::Call _c, int
> _id,
> void **_a) int MasterHandler::qt_metacall(QMetaObject::Call _c, int _id, void
> **_a)
> void QtPLWidget::qt_static_metacall(QObject *_o, QMetaObject::Call _c, int
> _id,
> void **_a) int QtPLWidget::qt_metacall(QMetaObject::Call _c, int _id, void
> **_a)
> void QtExtWidget::qt_static_metacall(QObject *_o, QMetaObject::Call _c, int
> _id,
> void **_a) int QtExtWidget::qt_metacall(QMetaObject::Call _c, int _id, void
> **_a)
>
> My C++ skills are not so hot, but I believe from the name coincidences that
> that last
> line of source code is instrumental in creating the demangled symbol,
> QtExtWidget::qt_metacall(QMetaObject::Call, int, void**) that is defined in
> the
> library here, but apparently somehow not defined there. So please try the
> above
> nm experiments on the relevant files there and also with the --define-only
> option
> replaced by --undefined-only to find whether the above specific symbols are
> defined
> or not there. Then follow up with similar analysis of moc_qt.cpp.
>
> When you attempt to replicate the above nm results and send them to me, please
> make sure the demangled symbol is exactly the same as mine so that we know
> that
> our mangled symbols refer to the same thing despite their different prefixes
> on my
> platform versus yours (your platform appears to have a prefix of "__imp__"
> while
> mine has no prefix at all). And if you can prove those demangled symbols are
> effectively defined by the moc-generated source code there like appears to be
> the
> case here, then we have a real puzzle unless all of this mess was generated
> by the
> -j4 make option on Cygwin.
>
> In sum, I am looking for a new report tarball without -j4 (in case that fix
> happens to
> affect the above undefined reference issue) from you, but if that doesn't
> appear to
> make a difference, then I am also asking for at least 8 "nm" results from you
> (the 4
> above and 4 more with the --undefined-only flag replaced in --defined-only
> flag) for
> the build without -j4 to investigate why the above symbol which is defined
> here both
> in the shared object and object is not defined there. And further analysis of
> the
> relevant moc-generated source code would be appreciated as well. Note I have
> attached a compressed version of
> bindings/qt_gui/pyqt4/plplot_pyqt4_automoc.dir/include/moc_qt.cpp
> so you can compare your moc-generated source-code results with mine.
>
> 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
> __________________________
DISCLAIMER: This message is intended exclusively for the addressee(s) and may
contain confidential and privileged information. If you are not the intended
recipient please notify the sender immediately and destroy this message.
Unauthorized use, disclosure or copying of this message is strictly prohibited.
The foundation 'Stichting Deltares', which has its seat at Delft, The
Netherlands, Commercial Registration Number 41146461, is not liable in any way
whatsoever for consequences and/or damages resulting from the improper,
incomplete and untimely dispatch, receipt and/or content of this e-mail.
------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
