Hi Arjen: Never mind about my request for you to do some nm experiments. (Although you might want to do those experiments in any case just to familiarize yourself with this very helpful tool for figuring out such undefined reference issues.)
>From my recent experiments here, I am virtually positive the issue concerns my workaround (in the plplot_pyqt4 shared object build) for a symbol visibility issue that was showing up on Linux. That shared object links to the plplotqt library which does define the appropriate moc-generated symbols. But those symbols were not visible (for the g++ -fvisibility=hidden option which more or less mimics the Windows visibility case) for my new automoc approach for running moc. So linking failed on Linux for plplot_pyqt4, and to work around that issue, I regenerated the moc results again specifically for plplot_pyqt4. That workaround worked here on Linux but obviously does not work on Cygwin for some reason that lots of nm investigation may eventually discover. But I don't care anymore (except for my curiosity which I don't have time to indulge right now) because the real issue is the visibility one for the plplotqt library, and it turns out my old method of moc generation did not have that visibility issue (and your old reports confirm in that case your build of the plplot_pyqt4 shared object went smoothly with that method, and I had similar success here on Linux). Furthermore, I have git bisected the visibility issue for the plplotqt library on a particular moc-generated symbol for that library, and indeed the first commit where the problem occurs corresponds exactly with when I switched from the old moc-generation method to the automoc approach. So my choices are to go back to the old method (which I don't particularly want to do because it is much clumsier than automoc) or figure out how to make the automoc-generated results for the plplotqt library visible on Linux. (By the way, the automoc generated result for the plplotqt library results in a build of that library with no issues on Cygwin. So there is nothing wrong there with automoc-generated results for that library other than their visibility to other software, e.g., the plplot_pyqt4 shared object.) Note also that plplot_pyqt5 has exactly the same issue (for the case where our qt device driver and plplotqt library are linked with Qt5). Anyhow, I hope to resolve this moc-generated symbol visibility issue for the plplotqt library today with one of the two methods above, and once that is done the build of the plplot_pyqt[45] shared objects should go well on both Linux and Cygwin without any build workarounds for plplot_pyqt[45]. More later.... 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 __________________________ ------------------------------------------------------------------------------ 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
